Динамические права

Система динамической выдачи прав доступа учётным записям

Управление учетными записями

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

Основа

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

Традиционно блокчейн-системы имеют следующие недостатки:

• Модель М из N не соответствует иерархии принятия решений во многих реальных организациях.

• Равномерное распределение весов на M ключей не позволяет перенести на блокчейн асимметричное владение учетной записью.

• Координацию и подписание требуется проводить за пределами основной системы.

• Ключи нельзя изменить без координации со всеми задействованными участниками.

• Подпись нельзя отозвать в процессе ожидания подписания от других участников.

Пример использования

Технология мультиподписи - технология о правах доступа, и распределение прав доступа должно соответствовать реальным жизненным ситуациям и реальным управленческим структурам. Представим, что существует компания, управляемая тремя индивидуумами: Алисой, Марком, Иваном. Алиса и Марк каждый владеют 40% акций компании, Иван - 20%. Для проведения операции по списанию средств в этой компании требуется подтверждения расходов от 2 из 3 владельцев. Можно для данной компании рассмотреть вариант с приватными ключами и использование мультиподписи 2 из 3. При этом Алиса может захотеть, например, управлять своей учетной записью через двухфакторную аутентификацию, поскольку это обеспечивает большую безопасность как Алисе, так и компании. Как сделать так, чтобы Алиса смогла использовать двухфакторную аутентификацию без внесения изменений в структуру прав доступа.

Решение

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

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

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

Описанный вариант требует структурирования процесса мультиподписания следующим образом:

• Кто-то предлагает транзакцию и одобряет её со своей учетной записи
• Другие пользователи добавляют "да", "нет" к транслируемой транзакции
• После того, как изначальная транзакция получает одобрение всех учётных записей, она подтверждается

Владелец и активные ключи

Каждая учетная запись имеет два вида управления: владелец и активный участник. Система управления представляет собой набор из ключей и (или) учётных записей, каждому (ой) из который присвоен свой весовой коэффициент. В каждой системе устанавливается свой "весовой" уровень, которые должен быть преодолён для совершения операции. Вид управления “владелец” создан для управления холодным хранением, и его первостепенная роль - назначение активных участников или изменение владельца. Вид управления “активный участник” предназначен для "горячего" (ежедневного) управления и может совершать все операции за исключением смены владельца.

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

Сбор подписей

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

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

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

Масштабирование

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

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

Цикличность

В системе возможна реализация функции запроса на одобрение транзакции друг у друга двумя учётными записями Представьте, создана учетная запись X, которая подтверждается учётными записями A и Y. Представьте далее, что создана учетная запись Y, которая подтверждается с учётных записей B и X. Символьно это можно записать как:

A -> X <-> Y B -> Y <-> X

А предлагает X потратить 1 единицу и ждёт одобрения Y. B предлагает Y одобрить предложение A и ждёт одобрения от X. Данную ситуацию невозможно разрешить в стандартной ситуации индивидуального одобрения транзакций по следующим причинам:

• Ни одна из учётных записей не может совершить действие без одобрения другой, соответственно, транзакция не может пройти
• Цикличность может быть гораздо более сложной и запутанной, чем в представленном примере
• При возникновении зацикливания в режиме активного участника возможно использование режима владельца для того, чтобы разорвать цикл. Однако, при возникновении зацикливания в режимах владельца и активного участника разрыв цикла невозможен. На практике ПО клиента может отслеживать ситуации зацикливания и не допускать их возникновения.

Вывод

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

Благодарности

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