Кухня криптоанархиста: инфраструктура открытых ключей (PKI)
Продолжаем знакомиться с темой «Криптография». Начало - здесь.
Криптография с открытым ключом - замечательная вещь, но есть ряд нюансов, которые могут отравить жизнь:
Что интересно, широко разрекламированная в литературе по защите данных проблема «человек посередине» хоть и выглядит весьма инфернально, в реальной жизни на такое попадают весьма редко. Дело в том, что для того, чтобы провернуть такую каверзу товарищ майор должен полностью собой перекрыть все каналы общения Алисы с Бобом. Как только Алиса пошлёт шифровку Бобу не как всегда из дома (предположим, спецслужбы вклинились через Алисиного провайдера), а из Макдональдса через бесплатный Wi-Fi, обман сразу вскроется. По-хорошему, MITM-проблема актуальна только когда хотя бы один из участников абсолютно статичен. Например, является сервером, с которым работают через SSL. Или же и обмен ключами, и передача шифровок идут плотно друг за другом, в рамках одного сеанса. Что, кстати, тоже характерно для SSL. Во всех остальных случаях MITM-атака - штука практически нереальная.
Функцией инфраструктуры открытых ключей является установка соответствия между личностью человека и открытым ключом, которым можно (а) зашифровать послание для этой личности и (б) проверить её электронную подпись.
Если среда общения полностью и стопроцентно анонимна как, например, система Bitmessage (по-русски, официальный сайт, техническое описание), то никакого понятия «личность» не возникает и возникнуть не может. В таком случае нет той пары сущностей, между которыми нужно протягивать соответствие, и поэтому открытый ключ (всё же, наверно, его хеш) - это и есть единственное имя адресата, которое может быть. Типа «Уважаемый(ая) 2nTX1KchxgnmHvy9ntCN9r7sgKTraxczzyE, имею честь сообщить Вам следующее. … … … С уважением, 6quxjcgj3feKlO0mmZBEB7sCtBko6SiRyMU». На первый взгляд, заманчиво, но на второй взгляд сразу три неприятности:
Рассмотрим существующие методы организации PKI.
Использование третьей стороны
Если Алиса ходит в гости к Кате и Боб ходит в гости к Кате, то Катю можно попросить стать удостоверяющим центром, способным подтверждать, что открытый ключ Алисы принадлежит действительно Алисе, а открытый ключ Боба - Бобу.
Когда Алиса получает от Боба письмо с новым открытым ключом, Алиса вполне логично может усомниться в том, что это действительно ключ Боба, а не происки товарища майора. Но если вместе с ключом она получит клятвенные заверения Кати (электронную подпись), что это действительно ключ Боба, она может сомневаться меньше.
Допустим, Боб сгенерил новую ключевую пару:
(PKB, SKB) = NewKeyPair()
После этого он пришёл ножками к Кате и принёс на флэшке PKB. Катя посмотрела на Боба, удостоверилась, что это действительно он, и создала сертификат открытого ключа Боба:
UserInfo = "Боб, рыжеволосый балбес, которого мы все знаем"
KeyBody = (PKB, UserInfo)
PKCB = (KeyBody, Sign(KeyBody, SKС))
И теперь если Боб пришлёт Алисе не PKB, а PKCB, то Алиса, доверяющая Кате, может чуточку меньше волноваться относительно неподдельности ключа Боба.
Этот подход настолько плотно внедрился в практику, что:
Сеть доверия
Если Алиса получила ключ Боба от него самого из рук в руки, она считает этот ключ надёжным на 100%. Если Боб получил ключ от Кати тоже из рук в руки, то он для него тоже надёжен на 100%. Если Алиса получает Катин ключ от Боба, Катин ключ для неё надёжен уже не на все сто, а процентов на 90. Мало ли что… Соответственно, доверие к ключу Даши, Катиной знакомой, ещё меньше потому что цепочка удлинилась на одно звено. По мере роста сети связность увеличивается, и сеть позволяет оценивать достоверность всё большего количества ключей, оставаясь при этом одноранговой (то есть без всяких особо «авторитетных» «авторитетов» в лице ФСБ).
В теории всё выглядит красиво, но пользоваться этим категорически неудобно. Ну невозможно нормальному человеку понять, что значит «степень доверия равна 63.8%». Доверие - такая вещь, которую не нужно даже пытаться мерить числом. Одному человеку я могу доверить чинить проводку, но ни за что не доверю ребёнка. А другому ни минуты не сомневаясь доверю ребёнка, но к проводке на пушечный выстрел не подпущу. И чему равна степень моего доверия этим людям? Точную цифру в процентах, пожалуйста.
Система PGP, в которой изначально появилась технология с сетью доверия, впоследствии отказалась от неё в пользу работы через удостоверяющие центры. Потому что пользователи не поняли и не приняли эту технологию. Функция, конечно, осталась, но ею совсем мало кто пользуется.
Итак, на настоящий момент имеем три архитектуры инфраструктур открытых ключей:
Отзыв ключей
Если секретный ключ потерялся или украден (или вынесен ребятами из маски-шоу), то нужно всех оповестить, что дальнейшее использование открытого ключа, мягко говоря, не очень безопасно. Стандартная процедура, применяемая в Матрице - прийти с паспортом в удостоверяющий центр, выдавший сертификат, написать заявление и объяснительную, после чего они включат сертификат в регулярно публикуемый список отзывов. В PGPшной сети доверия возможность отозвать сертификат тоже была реализована, но с наскоку у меня не получилось найти информацию о том, как это было реализовано.
Насколько я понимаю, основная сложность, связанная с отзывом ключа, заключается в том, что после того, как человек потерял свой секретный ключ, с точки зрения системы он перестал быть самим собой и с полным правом может рассматриваться как злоумышленник, решивший насолить приличному человеку включением его ключа в список отзывов. Этим и объясняется требование лично подтвердить свою личность в удостоверяющем центре. Но что делать, если никаких аккредитованных удостоверяющих центров не существует, а пышным цветом цветёт казачья вольница, где каждый сам себе хозяин? Куда идти с паспортом? От себя (от слова «отсебятина») могу предложить красивое решение этой проблемы, которое одновременно и надёжно, и функционально, и не запредельно сложно в реализации. Возможно, не я первый придумал это решение, но, по крайней мере, я о таком нигде не слышал и не читал.
Допустим, я предвижу, что мой секретный ключ могут украсть (в том числе и насовсем, то есть так, что я сам им больше воспользоваться не смогу), и поэтому заранее пишу ему некролог. RIP-файл:
RIP_file = (PK, Sign("R.I.P.", SK))
Этот файл я старательно куда-нибудь прячу - на то есть миллион разных способов, но, скорее всего, шифрую другими своими ключами и рассовываю по разным нычкам. Если вдруг мой ключ оказывается скомпрометирован, я этот цифровой некролог публикую. Мои товарищи, прежде чем отправить мне шифровку, обязаны проверить, не появился ли для моего открытого ключа некролог.
Игра здесь идёт на том, что:
Возвращаясь к теме PKI (ещё немножко отсебятины)
Выше я писал, что задача, решаемая PKI - это установка соответствия между личностью человека и открытым ключом. Для начала давайте разберёмся с терминологией.
Что такое открытый ключ - более-менее ясно, но есть маленький нюанс, который может оказаться небесполезным. Протягивать соответствие между самим открытым ключом и личностью - совсем не обязательно. Достаточно предоставить возможность установить соответствие между личностью и хешем открытого ключа. Это и технологически выгоднее, и даёт некоторые дополнительные возможности. Например, можно сделать так, чтобы об этом соответствии узнали не все желающие, а только те, у кого есть секретный пароль, добавляемый в вычисление хеша.
Без секретного пароля (пусть любой желающий может узнать соответствие) это бы выглядело так (имеем данные о пользователе UserInfo и его открытый ключ PK):
PKC = (UserInfo, Hash(PK))
Мы можем засекретить PK в этом соответствии, добавив пароль (Password):
PKC = (UserInfo, Hash(PK+Password))
В некоторых случаях это может быть очень полезно, например, для того, чтобы скрыть транзитное соответствие двух виртуальных личностей друг другу через один открытый ключ. Или для того, чтобы иметь возможность «расшифроваться» не сразу, а только тогда, когда того самому захочется.
С определением, что такое личность (субъект, другая часть устанавливаемого соответствия), всё намного сложнее и запутаннее. Ответ «двуногое без перьев, имеющее паспорт, ИНН и СНИЛС» - точно не правильный. Вернее, не полный. Возможные варианты:
Осталось только определиться, что такое соответствие. Соответствие - это функция, которую реализует PKI на том массиве данных, который в ней накапливается. Можно предположить, что логически соответствие может быть либо связкой «многие-к-одному» (многие ключи к одной личности) либо «многие-ко-многим». В любом случае получается так, что по правилам построения нормализованных баз данных, таблица соответствия не должна хранить в себе никакой описательной информации, относящейся к субъекту, а лишь ссылку на него. Исходя из этого, можно утверждать, что принятая в настоящее время практика, когда открытый ключ и сертификат открытого ключа, содержащий в себе персональные данные владельца, считается одной и той же сущностью - это с информационно-технологической точки зрения полная ерунда.
Давайте набросаем вчерне информационную модель внутреннего хранилища данных PKI-сервиса. Допустим, принято, что соответствие между субъектом и ключом - «многие-ко-многим». Мне не очень понятно, зачем это может быть, но готов допустить, что в некоторых ситуациях это может оказаться небесполезно. Реализуется такое через две таблицы, хранящие связываемые сущности (таблица ключей и таблица субъектов) и промежуточную таблицу-связку. Можно предложить такую структуру таблицы ключей:
Таблица субъектов:
Публикуемый «наружу» интерфейс PKI-сервиса часть хранящегося великолепия наверняка должен скрывать. Можно предположить, что минимальный набор функциональности, начиная с которого сервис может называться PKI-сервисом, будет заключаться в возможности подтвердить или опровергнуть связку между субъектом и ключом. Например, так: «Правда ли, что MD5-хеш ключа вашего пользователя Neo666 равен <…много цифр…>?» Если сервер хакерского сообщества не допускает дублирования имён своих пользователей, то на этот вопрос он сможет ответить «да» или «нет». Другие функции сервиса уже зависят от принятой политики безопасности, то есть от того, насколько хранимая информация является «чувствительной». Например, сервер форума цветоводов может публиковать в свободный доступ вообще все накопленные данные. Главное, чтобы пользователь, регистрирующийся на этом форуме, был об этом оповещён.
Стоит заметить, что PKI-сервис - это не обязательно выделенный сервер с нанятым на полную ставку сисадмином. Каждый пользователь в своём смартфоне может носить маленький личный карманный PKI-сервис, реализованный как одна из функций списка контактов.
Вывод: задача создания надёжной, безопасной, децентрализованной и функциональной сети PKI-сервисов имеет решение, и решение это, во-первых, не совпадает ни с чем, что существует и эксплуатируется в настоящий момент и, во-вторых, не является чем-то запредельно сложным. По сути, единственное, что для этого нужно - это желание. Ну и, конечно, способность договориться друг с другом.
Продолжение - вот здесь. Про пароли и аутентификацию.
Криптография с открытым ключом - замечательная вещь, но есть ряд нюансов, которые могут отравить жизнь:
- Если враг достаточно ловок и хитёр, он может подменить открытый ключ. То есть Алиса вместо открытого ключа Боба будет иметь открытый ключ товарища майора. Это чревато следующими неприятностями:
- Применительно к шифрованию: раскрывается тайна переписки. То есть товарищ майор читает всё, что Алиса будет писать Бобу.
- Применительно к электронной подписи: злоумышленник получает возможность действовать от имени другого человека. В данном случае, Боба. Таким образом, товарищ майор может гнать Алисе дезу и подставлять в её глазах Боба.
- Секретный ключ может быть потерян, сломан, уничтожен при пожаре. Если это случилось с Алисой, то в этом случае она имеет следующие проблемы:
- Она потеряла все свои данные, которые для себя зашифровала своим открытым (а каким же ещё?) ключом.
- Она не сможет прочитать то, что ей пишут, до тех пор, пока не разошлёт свой новый ключ всем своим корреспондентам. А если список контактов зашифрован, то сделать это не так просто, как того бы хотелось.
- Секретный ключ может быть украден врагом. В этом случае:
- Товарищ майор может прочитать всю входящую корреспонденцию Алисы. В том числе и ту, которую он заботливо скопил за многие годы.
- Товарищ майор может от имени Алисы творить любые безобразия, вводя в заблуждение её товарищей.
- Если о факте кражи Алиса не узнала, и товарищ майор в достаточной мере осторожен, эти безобразия он может творить неограниченно долго.
- Кроме того, сам Боб может оказаться подлецом, изменщиком или даже вообще тем самым товарищем майором, которого Алиса больше всего боится. Казалось бы, эта проблема к технике и технологиям не имеет отношения, но на самом деле имеет. Коммуникационная среда - это человеко-машинный комплекс, и в случае компрометации Боба оказывается скомпрометированным не только он сам, но и вся та часть инфраструктуры, в которую он внёс свой злонамеренный вклад.
Что интересно, широко разрекламированная в литературе по защите данных проблема «человек посередине» хоть и выглядит весьма инфернально, в реальной жизни на такое попадают весьма редко. Дело в том, что для того, чтобы провернуть такую каверзу товарищ майор должен полностью собой перекрыть все каналы общения Алисы с Бобом. Как только Алиса пошлёт шифровку Бобу не как всегда из дома (предположим, спецслужбы вклинились через Алисиного провайдера), а из Макдональдса через бесплатный Wi-Fi, обман сразу вскроется. По-хорошему, MITM-проблема актуальна только когда хотя бы один из участников абсолютно статичен. Например, является сервером, с которым работают через SSL. Или же и обмен ключами, и передача шифровок идут плотно друг за другом, в рамках одного сеанса. Что, кстати, тоже характерно для SSL. Во всех остальных случаях MITM-атака - штука практически нереальная.
Функцией инфраструктуры открытых ключей является установка соответствия между личностью человека и открытым ключом, которым можно (а) зашифровать послание для этой личности и (б) проверить её электронную подпись.
Если среда общения полностью и стопроцентно анонимна как, например, система Bitmessage (по-русски, официальный сайт, техническое описание), то никакого понятия «личность» не возникает и возникнуть не может. В таком случае нет той пары сущностей, между которыми нужно протягивать соответствие, и поэтому открытый ключ (всё же, наверно, его хеш) - это и есть единственное имя адресата, которое может быть. Типа «Уважаемый(ая) 2nTX1KchxgnmHvy9ntCN9r7sgKTraxczzyE, имею честь сообщить Вам следующее. … … … С уважением, 6quxjcgj3feKlO0mmZBEB7sCtBko6SiRyMU». На первый взгляд, заманчиво, но на второй взгляд сразу три неприятности:
- Средство общения - это всегда средство общения между людьми, а не кодовыми последовательностями. Если я интересуюсь чьим-то мнением, обращаюсь к кому-то с просьбой, делюсь новостями, то я в любом случае «на том конце провода» подразумеваю живых людей, а не абстрактные «cBdFkP0s3cXeDANgz3ee7csLZqKvpTGl9uX» или «wz5BmFpM4mMfOJ4ryz9c4tQlJtmsVLvHffc». То есть я где-то у себя должен иметь бумажечку, на которой написано, что cBdFkP0s3cXeDANgz3ee7csLZqKvpTGl9uX - это Вася, а wz5BmFpM4mMfOJ4ryz9c4tQlJtmsVLvHffc - это Федя. Я сам себе должен стать инфраструктурой открытых ключей, сам у себя должен протянуть соответствие между людьми и ключами. Смогу ли я это сделать правильно, и не буду ли я при этом несколько раз обманут - очень большой вопрос. У нас это называется «переложить технологические трудности на хрупкие плечи пользователя».
- Что мне делать, если мой секретный ключ украден врагами? Как мне быстро оповестить соратников, что адрес изменился и по старому адресу больше ничего слать не нужно?
- Если полностью анонимный для меня чел «W1KhgYUvxv9AF37qGbBMI287pOdVQAucDpE» мамой клянётся (методом простановки электронной подписи), что… не важно что, потому что какой смысл в этой клятве, если она дана неизвестно кем? У нас это называется «существенное урезание функциональности».
Рассмотрим существующие методы организации PKI.
Использование третьей стороны
Если Алиса ходит в гости к Кате и Боб ходит в гости к Кате, то Катю можно попросить стать удостоверяющим центром, способным подтверждать, что открытый ключ Алисы принадлежит действительно Алисе, а открытый ключ Боба - Бобу.
Когда Алиса получает от Боба письмо с новым открытым ключом, Алиса вполне логично может усомниться в том, что это действительно ключ Боба, а не происки товарища майора. Но если вместе с ключом она получит клятвенные заверения Кати (электронную подпись), что это действительно ключ Боба, она может сомневаться меньше.
Допустим, Боб сгенерил новую ключевую пару:
(PKB, SKB) = NewKeyPair()
После этого он пришёл ножками к Кате и принёс на флэшке PKB. Катя посмотрела на Боба, удостоверилась, что это действительно он, и создала сертификат открытого ключа Боба:
UserInfo = "Боб, рыжеволосый балбес, которого мы все знаем"
KeyBody = (PKB, UserInfo)
PKCB = (KeyBody, Sign(KeyBody, SKС))
И теперь если Боб пришлёт Алисе не PKB, а PKCB, то Алиса, доверяющая Кате, может чуточку меньше волноваться относительно неподдельности ключа Боба.
Этот подход настолько плотно внедрился в практику, что:
- Стал промышленным стандартом, используемым как в бизнесе, так и государственными органами.
- Создана гигантская инфраструктура центров сертификации, включающая в себя и правовое обеспечение, и поддержку «из коробки» основными операционными системами, и, собственно, сами удостоверяющие центры, работающие как при госструктурах и службах безопасности корпораций, так и просто за деньги. В нашей стране курирует это всё (выдаёт лицензии, следит за деятельностью), конечно же, ФСБ.
- Когда речь заходит об открытых ключах (public key, PK), уже без тени сомнения как слово-синоним применяется понятие «сертификат» (public key certificate, PKC), хотя, конечно же, это разные вещи.
Сеть доверия
Если Алиса получила ключ Боба от него самого из рук в руки, она считает этот ключ надёжным на 100%. Если Боб получил ключ от Кати тоже из рук в руки, то он для него тоже надёжен на 100%. Если Алиса получает Катин ключ от Боба, Катин ключ для неё надёжен уже не на все сто, а процентов на 90. Мало ли что… Соответственно, доверие к ключу Даши, Катиной знакомой, ещё меньше потому что цепочка удлинилась на одно звено. По мере роста сети связность увеличивается, и сеть позволяет оценивать достоверность всё большего количества ключей, оставаясь при этом одноранговой (то есть без всяких особо «авторитетных» «авторитетов» в лице ФСБ).
В теории всё выглядит красиво, но пользоваться этим категорически неудобно. Ну невозможно нормальному человеку понять, что значит «степень доверия равна 63.8%». Доверие - такая вещь, которую не нужно даже пытаться мерить числом. Одному человеку я могу доверить чинить проводку, но ни за что не доверю ребёнка. А другому ни минуты не сомневаясь доверю ребёнка, но к проводке на пушечный выстрел не подпущу. И чему равна степень моего доверия этим людям? Точную цифру в процентах, пожалуйста.
Система PGP, в которой изначально появилась технология с сетью доверия, впоследствии отказалась от неё в пользу работы через удостоверяющие центры. Потому что пользователи не поняли и не приняли эту технологию. Функция, конечно, осталась, но ею совсем мало кто пользуется.
Итак, на настоящий момент имеем три архитектуры инфраструктур открытых ключей:
- «Нулевой вариант», как в Bitmessage.
- Сеть удостоверяющих центров, как в Матрице.
- Сеть доверия, как в PGP.
Отзыв ключей
Если секретный ключ потерялся или украден (или вынесен ребятами из маски-шоу), то нужно всех оповестить, что дальнейшее использование открытого ключа, мягко говоря, не очень безопасно. Стандартная процедура, применяемая в Матрице - прийти с паспортом в удостоверяющий центр, выдавший сертификат, написать заявление и объяснительную, после чего они включат сертификат в регулярно публикуемый список отзывов. В PGPшной сети доверия возможность отозвать сертификат тоже была реализована, но с наскоку у меня не получилось найти информацию о том, как это было реализовано.
Насколько я понимаю, основная сложность, связанная с отзывом ключа, заключается в том, что после того, как человек потерял свой секретный ключ, с точки зрения системы он перестал быть самим собой и с полным правом может рассматриваться как злоумышленник, решивший насолить приличному человеку включением его ключа в список отзывов. Этим и объясняется требование лично подтвердить свою личность в удостоверяющем центре. Но что делать, если никаких аккредитованных удостоверяющих центров не существует, а пышным цветом цветёт казачья вольница, где каждый сам себе хозяин? Куда идти с паспортом? От себя (от слова «отсебятина») могу предложить красивое решение этой проблемы, которое одновременно и надёжно, и функционально, и не запредельно сложно в реализации. Возможно, не я первый придумал это решение, но, по крайней мере, я о таком нигде не слышал и не читал.
Допустим, я предвижу, что мой секретный ключ могут украсть (в том числе и насовсем, то есть так, что я сам им больше воспользоваться не смогу), и поэтому заранее пишу ему некролог. RIP-файл:
RIP_file = (PK, Sign("R.I.P.", SK))
Этот файл я старательно куда-нибудь прячу - на то есть миллион разных способов, но, скорее всего, шифрую другими своими ключами и рассовываю по разным нычкам. Если вдруг мой ключ оказывается скомпрометирован, я этот цифровой некролог публикую. Мои товарищи, прежде чем отправить мне шифровку, обязаны проверить, не появился ли для моего открытого ключа некролог.
Игра здесь идёт на том, что:
- Пока злоумышленник не украл мой секретный ключ, он может хотеть опубликовать на него некролог, но не может этого сделать, потому что не может сгенерировать мою электронную подпись к всего лишь шести байтам, к строчке «R.I.P.».
- Когда злоумышленник завладел моим ключом, ему больше нет никакого интереса публиковать RIP-файл. Ему как раз нужно, чтобы как можно дольше никто этот файл не увидел.
- Создать инфраструктуру публикации цифровых некрологов. Понятное дело, децентрализованную и распределённую. С многократным дублированием. Достаточно быструю. «Облачную».
- Встроить проверку в средства шифрования и проверки электронной подписи.
- Прикрутить кнопку создания RIP-файла в средство управления собственными ключами.
Возвращаясь к теме PKI (ещё немножко отсебятины)
Выше я писал, что задача, решаемая PKI - это установка соответствия между личностью человека и открытым ключом. Для начала давайте разберёмся с терминологией.
Что такое открытый ключ - более-менее ясно, но есть маленький нюанс, который может оказаться небесполезным. Протягивать соответствие между самим открытым ключом и личностью - совсем не обязательно. Достаточно предоставить возможность установить соответствие между личностью и хешем открытого ключа. Это и технологически выгоднее, и даёт некоторые дополнительные возможности. Например, можно сделать так, чтобы об этом соответствии узнали не все желающие, а только те, у кого есть секретный пароль, добавляемый в вычисление хеша.
Без секретного пароля (пусть любой желающий может узнать соответствие) это бы выглядело так (имеем данные о пользователе UserInfo и его открытый ключ PK):
PKC = (UserInfo, Hash(PK))
Мы можем засекретить PK в этом соответствии, добавив пароль (Password):
PKC = (UserInfo, Hash(PK+Password))
В некоторых случаях это может быть очень полезно, например, для того, чтобы скрыть транзитное соответствие двух виртуальных личностей друг другу через один открытый ключ. Или для того, чтобы иметь возможность «расшифроваться» не сразу, а только тогда, когда того самому захочется.
С определением, что такое личность (субъект, другая часть устанавливаемого соответствия), всё намного сложнее и запутаннее. Ответ «двуногое без перьев, имеющее паспорт, ИНН и СНИЛС» - точно не правильный. Вернее, не полный. Возможные варианты:
- Двуногое без перьев, имеющее паспорт, ИНН и СНИЛС. Физлицо, если в юридических терминах. Эту личность можно поймать, оштрафовать, посадить в тюрьму, расстрелять. Но можно и наградить, повысить в должности, возвеличить.
- Виртуальная личность. Один и тот же Кузькин Матвей Иванович может быть и юзером @kuzkinmat в Твиттере, и персонажем Садовник на форуме цветоводов, и зловещим Neo666 в сообществе хакеров. И это будут совсем разные личности, сильно различающиеся и по повадкам, и по характеру творимых дел. При этом информация о соответствии одних виртуальных личностей физлицу может старательно афишироваться, вторых - не афишироваться, а третьих - старательно скрываться. И это нормально.
- Организация. Например, для ключа фирмы Apple, которым подписываются приложения в AppStore, владельцем является фирма Apple.
- Роль в организации. Например, таким субъектом может быть главный бухгалтер организации, специалист службы технической поддержки, диспетчер и т.п. Какое конкретно физлицо исполняет роль, как его зовут - это не очень важно. Ключ может быть передаваемым при «пост сдал - пост принял».
- Сообщество. Аналогично организации, но только не оформлено юридически.
- Прибор. Желание иметь шифрованный канал связи с собственным холодильником - это, конечно, смешно, но, думаю, мало кто откажется иметь безопасную связь с бортовым компьютером своего автомобиля.
- Сервис. Например, PKI-сервис форума хакеров, на котором Кузькин Матвей известен как Neo666.
- … можно ещё придумать множество разнообразных и причудливых вариантов для того, что может стать объектом «на том конце провода».
- Видимо, с криптографической точки зрения личностью может выступать всё, что может (а) вступить в коммуникацию и (б) что может применять секретный ключ. И то, и другое, понятное дело, через посредство каких угодно механизмов, возможно, включающих в себя и живых людей. Ну и, конечно, (в) если в этом есть хоть какой-то смысл.
Осталось только определиться, что такое соответствие. Соответствие - это функция, которую реализует PKI на том массиве данных, который в ней накапливается. Можно предположить, что логически соответствие может быть либо связкой «многие-к-одному» (многие ключи к одной личности) либо «многие-ко-многим». В любом случае получается так, что по правилам построения нормализованных баз данных, таблица соответствия не должна хранить в себе никакой описательной информации, относящейся к субъекту, а лишь ссылку на него. Исходя из этого, можно утверждать, что принятая в настоящее время практика, когда открытый ключ и сертификат открытого ключа, содержащий в себе персональные данные владельца, считается одной и той же сущностью - это с информационно-технологической точки зрения полная ерунда.
Давайте набросаем вчерне информационную модель внутреннего хранилища данных PKI-сервиса. Допустим, принято, что соответствие между субъектом и ключом - «многие-ко-многим». Мне не очень понятно, зачем это может быть, но готов допустить, что в некоторых ситуациях это может оказаться небесполезно. Реализуется такое через две таблицы, хранящие связываемые сущности (таблица ключей и таблица субъектов) и промежуточную таблицу-связку. Можно предложить такую структуру таблицы ключей:
- Уникальный идентификатор (первичный ключ таблицы)
- Значение открытого ключа.
- Хеш открытого ключа (чисто для ускорения поиска по хешу).
- Алгоритм асимметричного шифрования.
- Закешированная информация о наличии в природе RIP-файла к этому ключу.
Таблица субъектов:
- Уникальный идентификатор (первичный ключ таблицы)
- <всякая разная информация о субъекте, состав которой сильно зависит от назначения и особенностей конкретного PKI-сервиса>
- Уникальный идентификатор ключа
- Уникальный идентификатор субъекта
- Дополнительная информация связки: период действия ключа, допустимые применения ключа, дата регистрации в PKI, дата появления RIP-файла, обстоятельства отзыва ключа и/или другие сведения, в зависимости от назначения и особенностей конкретного PKI-сервиса.
Публикуемый «наружу» интерфейс PKI-сервиса часть хранящегося великолепия наверняка должен скрывать. Можно предположить, что минимальный набор функциональности, начиная с которого сервис может называться PKI-сервисом, будет заключаться в возможности подтвердить или опровергнуть связку между субъектом и ключом. Например, так: «Правда ли, что MD5-хеш ключа вашего пользователя Neo666 равен <…много цифр…>?» Если сервер хакерского сообщества не допускает дублирования имён своих пользователей, то на этот вопрос он сможет ответить «да» или «нет». Другие функции сервиса уже зависят от принятой политики безопасности, то есть от того, насколько хранимая информация является «чувствительной». Например, сервер форума цветоводов может публиковать в свободный доступ вообще все накопленные данные. Главное, чтобы пользователь, регистрирующийся на этом форуме, был об этом оповещён.
Стоит заметить, что PKI-сервис - это не обязательно выделенный сервер с нанятым на полную ставку сисадмином. Каждый пользователь в своём смартфоне может носить маленький личный карманный PKI-сервис, реализованный как одна из функций списка контактов.
Вывод: задача создания надёжной, безопасной, децентрализованной и функциональной сети PKI-сервисов имеет решение, и решение это, во-первых, не совпадает ни с чем, что существует и эксплуатируется в настоящий момент и, во-вторых, не является чем-то запредельно сложным. По сути, единственное, что для этого нужно - это желание. Ну и, конечно, способность договориться друг с другом.
Продолжение - вот здесь. Про пароли и аутентификацию.