Реализация MSP с Identity Mixer =============================== Что такое Idemix? ----------------- Idemix - набор криптографических протоколов, обеспечивающих надежную аутентификацию вкупе с сохраняющими конфиденциальность свойствами, такими как **анонимность**, возможность совершать транзакции без выдачи сторон транзакции, и **несвязность** (unlinkability), возможность совершить одной identity несколько транзакций, не выдав, что все эти транзакции были совершены одной и той же identity. В процесс Idemix вовлечены три актора: **пользователь** (user), **издатель** (issuer) и **верификатор** (verifier). .. image:: images/idemix-overview.png * Издатель удостоверяет набор атрибутов пользователя - выпускает цифровой сертификат, далее именуемый "удостоверение" (credential). * Потом пользователь генерирует "`доказательство с нулевым разглашением `_ (zero knowledge proof), что он владеет удостоверением и также выборочно раскрывает какие хочет атрибуты. Так как доказательство ничего не разглашает, оно не раскрывает никакой другой информации про верификатора, издателя или кого-либо еще. Например, предположим, что Алиса хочет доказать Бобу (сотруднику магазина), что она владеет водительскими правами, изданным ГИБДД. В этом сценарии Алиса --- пользователь, ГИБДД --- издатель, а Боб --- верификатор. Для того, чтобы доказать свое владение правами, она может их ему показать, но тогда Боб узнает имя Алисы, адрес, возраст и т.д. --- и узнает гораздо больше информации, чем надо. Вместо этого Алиса может использовать Idemix, чтобы создать доказательство с нулевым разглашением для Боба, которое раскрывает только наличие корректных водительских прав Таким образом, из доказательства: * Боб не узнает никакой дополнительной информации об Алисе, кроме того, что она владеет правами (анонимность) * Если Алиса несколько раз придет в магазин и каждый раз создаст новое доказательство, Боб не сможет понять, что эти доказательства создал один и тот же человек (несвязность). Технология аутентификации Idemix обеспечивает модель доверия и гарантии безопасности, схожие с теми, что дают стандартные сертификаты X.509, но с криптографическими алгоритмами, обеспечивающими поддержку вышеобозначенных свойств. Сравнение технологий X.509 и Idemix последует далее. Как использовать Idemix ----------------------- Сначала давайте разберемся, какие компоненты Hyperledger Fabric отвечают за пользователя, издателя и верификатора. * Fabric Java SDK - API для **пользователя**. В будущем, другие SDK Fabric также будут поддерживать Idemix. * Fabric предоставляет два возможных Idemix **издателя**: a) Fabric CA для промышленного использования или разработки, и b) :doc:`idemixgen ` для использования во время разработки. * **Верификатор** --- Idemix MSP. .. image:: images/idemix-three-steps.png 1. Рассмотрим издателя. Fabric CA (версии 1.3 и больше) может автоматически функционировать как Idemix издатель. При запуске ``fabric-ca-server`` (или при инициализации с ``fabric-ca-server init``), следующие два файла автоматически создаются в домашней директории ``fabric-ca-server``: ``IssuerPublicKey`` и ``IssuerRevocationPublicKey``. Эти файлы понадобятся в пункте 2. Для разработки или в случае, если в не используете Fabric CA, вы можете использовать ``idemixgen`` для создания этих файлов. 2. Рассмотрим верификатора. Вам потребуется создать Idemix MSP с помощью ``IssuerPublicKey`` and ``IssuerRevocationPublicKey`` пункта 1. К примеру, давайте рассмотрим следующий фрагмент `configtx.yaml из примера с Hyperledger Java SDK `_: .. code:: bash - &Org1Idemix # defaultorg определяет организацию, используемую в sampleconfig # окружения разработки fabric.git name: idemixMSP1 # id, чтобы загрузить определение MSP как id: idemixMSPID1 msptype: idemix mspdir: crypto-config/peerOrganizations/org3.example.com Тип ``msptype`` указан как ``idemix`` и содержимое директории ``mspdir`` (``crypto-config/peerOrganizations/org3.example.com/msp`` в этом примере) включает файлы ``IssuerPublicKey`` и ``IssuerRevocationPublicKey``. Заметьте, что в этом примере ``Org1Idemix`` представляет Idemix MSP для организации ``Org1`` (не показано), также имеющей X509 MSP. 3. Рассмотрим пользователя. Напомним, что Java SDK - API пользователя. Для использования Idemix с JavaSDK необходим только один дополнительный вызов API: метод ``idemixEnroll`` класса ``org.hyperledger.fabric_ca.sdk.HFCAClient``. Давайте предположим, что ``hfcaClient`` --- объект HFCAClient, а ``x509Enrollment`` --- ваш ``org.hyperledger.fabric.sdk.Enrollment``, связанный вашим сертификатом X509. Следующий код присвоит idemixEnrollment объект ``org.hyperledger.fabric.sdk.Enrollment``, связанный с вашим удостоверением Idemix. .. code:: bash IdemixEnrollment idemixEnrollment = hfcaClient.idemixEnroll(x509enrollment, "idemixMSPID1"); Заметьте, что ``IdemixEnrollment`` реализует интерфейс ``org.hyperledger.fabric.sdk.Enrollment`` и, следовательно, может быть использован также, как и X509 enrollment object. Idemix и чейнкод ---------------- С точки зрения верификатора, необходимо рассмотреть только еще одного актора: чейнкод. Что чейнкод может узнать узнать о том, кто совершает транзакцию, если используется Idemix? `Библиотека cid (Client Identity) `_ (только для Go) была расширена, чтобы поддерживать функцию ``GetAttributeValue`` при использовании удостоверений Idemix. Однако, как упомянуто в секции "Текущие ограничения" ниже, в случае Idemix раскрываются только два атрибута: ``ou`` и ``role``. Если удостоверение было выдано Fabric CA: * значение атрибута `ou` (организационное подразделение) определяет **принадлежность** identity (например, "org1.department1"); * значением атрибута ``role`` может быть либо 'member', либо 'admin'. 'admin' означает, что identity - администратор MSP. По умолчанию, identites, созданные Fabric CA будут иметь роль 'member'. Для того, чтобы создать 'admin' identity, зарегестрируйте identity с атрибутом ``role`` со значением ``2``. Пример установки принадлежности в Java SDK: `пример `_. Пример использования библиотеки CID в чейнкоде Go для получения атрибутов: `go chaincode `_. Организации Idemix не могут быть использованы для подтверждения или одобрения определения чейнкода. Это необходимо учесть при установке политик канала LifecycleEndorsement и Endorsement. Текущие Ограничения ------------------- Текущая версия Idemix имеет несколько ограничений. * **Idemix организации и политики подтверждения** Организации Idemix не могут быть использованы для подтверждения или одобрения определения чейнкода. По умолчанию, политики ``Channel/Application/LifecycleEndorsement`` и ``Channel/Application/Endorsement`` требуют подписи большинства организаций канала. Из-за этого канал с большим числом Idemix организаций может не достичь большинства, чтобы удовлетворить стандартную политику. Например, если канал имеет две MSP организации и две Idemix организации, то политика канала потребует, чтобы определение чейнкода одобрили три из четырех организаций, чего, на данный момент, достичь в такой ситуации невозможно. Если ваш канал использует достаточно больше число Idemix организаций, чтобы повлиять на политику подтверждения, вы можете использовать `Signature` политику, чтобы указать, что необходимы именно MSP организации. * **Фиксированный набор атрибутов** Пока что не возможно выпустить или использовать удостоверение Idemix с пользовательскими атрибутами. Они будут добавлены в будущих релизах. Поддерживаются следующие четыре атрибута: 1. Атрибут организационного подразделения ("ou"): - Использование: как в X.509 - Тип: строка - Раскрывается: всегда 2. Атрибут роли ("role"): - Использование: как в X.509 - Тип: число - Раскрывается: всегда 3. Атрибут Enrollment ID - Использование: уникально идентифицировать пользователя --- ID одно и то же во все enrollment-удостоверениях одного пользователя (в следующих релизах оно будет использоваться для проведения аудита) - Тип: BIG - Раскрывается: никогда в подписи, только при создании токена аутентификации Fabric CA 4. Revocation Handle attribute - Использование: уникально идентицирует удостоверение (будет использоваться для отзыва удостоверений в будущих релизах) - Тип: число - Раскрывается: никогда * **Отзыв сертификатов пока не реализован** Хотя уже достатачная часть этого уже реализована, пока что отзыв удостоверений Idemix не поддерживается. * **Пиры не могут использовать Idemix для подтверждения** На текущий момент Idemix MSP используется пирами только для проверки подписей. Подпись с Idemix возможна только через Client SDK. Больше ролей (включая роль 'peer') будут реализованы позже. Техническое резюме ------------------ Сравнение удостоверений Idemix с сертификатами X.509 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Идея сертификата/удостовереня и процесс их издания (issuance) Idemix и X.509 подобны: набор атрибутов с цифровой подписью, неподделываемых, с секретным ключем, с которым крпиптографически связано удостоверение. Главное отличие между X.509 и Idemix в схеме подписи, используемой для подтверждения атрибутов. Подписи Idemix позволяют доказывать владение подписью, секретным ключом и соответствующими атрибутами без выдачи подписи и самих атрибутов, с помощью доказательств с нулевым разглашением. Доказательства, такие как сертификаты X.509, могут быть проверены публичным ключом центра, подписавшего удостоверение. Только пользователь знает секретный ключ удостоверения и может создавать доказательства о удостоверении и его атрибутах. Для проверки подписи сертификата X.509 необходимо выдать все его атрибуты, поэтому несколько использований одного сертификата можно связать вместе, пропадает *несвязность*. Для того, чтобы избежать связности, необходимо каждый раз выписывать новый сертификат X.509, что выльется в сложную систему управления ключами и связанные с этим расходы по хранению сертификатов и связи с системой. Также бывают случаи, когда необходимо обеспечить то, что даже издатель сертификатов не может связать транзакции между собой и с пользователем. Idemix помогает избежать связности, которую не может обнаружить даже CA (издатель) или верификатор, так как CA не может связать доказательства с нулевым разглашением и первоначальное удостоверение. Никто не может узнать, исходят ли два доказательства от одного и того же удостоверения, или от двух разных. Больше информации про идеи и возможности технологии Identity Mixer вы можете найти здесь: `Concepts and Languages for Privacy-Preserving Attribute-Based Authentication `_. Информация о топологии сети ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Имея в виду вышеобозначенные ограничения, рекомендуется иметь только одну Idemix MSP на канал, или, в крайнем случае, на сеть. Например, если иметь несколько Idemix MSP в одном канале, то можно будет, основываясь на информации из реестра канала, различить, какие транзакции были подписаны организациями одной Idemix MSP, а какие - другой. Это происходит из-за того, что транзакция раскрывает MSP-ID того, кто ее подписал. Другими словами, Idemix обеспечивает анонимность только клиентам одного MSP (организации). В будущем, Idemix будет расширен, чтобы поддерижвать анонимные иерархии Idemix CA, чьи удостоверения можно проверить по уникальному публичному ключу, так обеспечивая анонимность среди клиентов разных MSP (организаций). В принципе, канал мжоет быть настроен так, чтобы иметь один Idemix MSP и несколько X.509 MSP. Конечно, взаимодействие между этими MSP может раскрывать некоторую информацию, какую именно --- зависит от случая. Использующиеся криптографические протоколы ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Технология Idemix использует схему слепой подписи (blind signature), поддерживающую подпись нескольких сообщений сразу и эффективных доказательств владения подписью с нулевым разглашением. Все криптографические протоколы, используемые Idemix, были опубликованы на лучших конференциях и журналах, и проверены научным сообщенством. Реализация Idemix для Fabric использует pairing-based signature scheme, предложенную `Camenisch and Lysyanskaya `_ и описанную в деталях `Au et al. `_. Возможность доказывать знание подписи через доказательство с нулевым разглашением: `Camenisch et al. `_. .. Licensed under Creative Commons Attribution 4.0 International License https://creativecommons.org/licenses/by/4.0/