Зравствуйте, уважаемые форумчане.
Я хочу предоставить Вашему вниманию обзор идей, которые мы применяем в нашем проекте и надеюсь услышать Ваше мнение, конструктивную критику, предложения.
В рамках проекта по созданию системы проведения транзакций, подходящей для использования в розничных расчетах для самых обычных людей, который мы начали некоторое время назад, основной целью было создать систему распределенного учёта транзакций, где вопрос безопасности средств участников сети имеет высший приоритет и которая позволяла бы проводить транзакции не раскрывая чувствительной финансовой информации контрагентов. Требования относительно этого, которые мы поставили перед собой, были следующие:
1. Многофакторная авторизация транзакции.
2. Исключение возможности сведения вектора атаки в одно место даже теоретически.
3. Возможность изменения средств авторизации при компрометации доступа к аккаунту.
4. Стойкость к утере средств даже в случае успешного взлома аккаунта.
5. Восстанавливаемость аккаунтов при частичной утере способов авторизации.
6. Возможность распределенного хранения всей возможной и необходимой информации в зашифрованном виде.
7. Сохранение тайны количества средств, имеющихся на счету.
8. Предоставить возможность ведения нескольких аккаунтов без необходимости хранения на каких-либо устройствах дополнительной информации.
Последний пункт нуждается в большем раскрытии для полного понимания. Рассмотрим ситуацию, когда покупатель приходит в магазин и оплачивает товар. После совершения транзакции покупателю, при условии что пункт (7) реализован правильно, всё ещё доступна информация если не количественная, то качественная о всех источниках и назначениях транзакций, совершенных до текущей, а при известном желании и всех последующих тоже. Чтобы как-то скрыть наиболее чувствительную часть транзакций можно вести несколько счетов, но тут встаёт проблема, что чем больше счетов, тем больше приватных ключей, которые надо безопасно хранить. Поэтому мы предложили способ, когда с одним приватным ключём можно иметь сколько угодно аккаунтов, так как это сильно упростит организационные проблемы ведения множества счетов.
Предложения реализации
Для того, чтобы достич выполнения всех поставленных задач было решено использовать мета-данные, которые будут храниться в самом распределенном реестре. Собственно, из пункта (6) и следует, что наиболее очевидным средством достижения требуемой функциональности в распределенных реестрах - это использование метаданных в самом распределенном реестре.
Из пункта (3) следует, что метаданные должны и сами быть объектами транзакций, с тем отличием, что в случае операции на метаданных транзакция переводит объект из одного состояния в другое без изменения принадлежности объекта.
Относительно обеспечения многофакторной авторизации транзакций (пункт (1)) достаточным решением может стать использование, так называемых, мультиподписных кошельков. Но рассматривая пункт (2) мы пришли к выводу, что использование мультиподписных кошельков не достаточно удовлетворяет поставленным требованиям, так как они теоретически остаются потенциальным единым местом для вектора атаки. Более того, учитывая пункты (4) и (5) становится ясно, что сама архитектура распределенного реестра и способ регистрации транзакций должны стать таковыми, чтобы обеспечивать поставленные требования. То есть транзакции и сами должны стать распределенными и по времени и по пространству, а не исходить из единой точки.
Относительно пункта (7), то наиболее очевидным решением являются Конфиденциальные Транзакции (Confidential Transactions) с ослепляющим фактором.
А решение для пункта 8 станет ясным из продолжения статьи.
Технологический обзор
На сегодняшний день существует три основных способа построения распределенных реестров:
1. Блокчейн
2. Направленный ациклический граф (DAG)
3. Блок-решетка (Block-lattice)
В силу сложившегося способа финализации транзакций в распределенных реестрах типа блокчейн и DAG и учитывая необходимость наибыстрейшей финализации транзакций для расчетов в розничных операциях, наиболее подходящим способом построения распределенного реестра был определен Блок-решетка, где можно достич времени финализации транзакции до нескольких секунд.
Для рассмотрения процессов и операций, выполняемых в блок-решетке нашей системы рассмотрим сущности, над которыми выполняются процессы и операции:
Основной аккаунт - аккаунт представляемый парой приватный - публичный ключ. Может инициировать только транзакции изменения мета-данных и используется как "отправная точка" для формирования аккаунтов, предназначенных для проведения транзакций и как место хранения мета-данных. Одним из важнейших видов мета-данных, хранимых в основном аккаунте (разумеется в зашифрованном виде) является ключ шифрования и имена для транзакционных аккаунтов, о которых рассказано ниже.
Также основной аккаунт хранит N-кратный хеш пароля, который используется для доступа к аккаунту.
Транзакционный аккаунт - аккаунт, на котором хранятся средства и который служит для передачи и приема средств. Транзакционный аккаунт является единственно возможным источником инициации транзакции для перевода средств. На каждый основной аккаунт может быть один или больше транзакционных аккаунтов. Каждый транзакционный аккаунт имеет имя, которое используется как его идентификатор. Если быть точнее, то идентификатором транзакционного аккаунта является N-кратный 160 битный хеш от имени транзакционного аккаунта, которое было зашифрованно с помощью ключа шифрования, хранимого в основном аккаунте. Таким образом, с одной стороны обеспечивается невозможность для стороннего наблюдателя соотнести транзакционные аккаунты с основным и между собой, а с другой, при знании одного единственного приватного ключа, обеспечивается работа с несколькими транзакционными аккаунтами без необходимости хранения множества секретных ключей.
Верификационный аккаунт - виртуальный аккаунт, используемый только для авторизации транзакций, инициированных транзакционными аккаунтами и транзакций изменения мета-данных в транзакционных и основном аккаунтах. Верификационный аккаунт должен держаться на отдельном устройстве, в частности на сотовом телефоне.
Доверенный аккаунт - основной аккаунт другого пользователя которому владелец текущего основного аккаунта доверяет и предоставляет на хранение некоторую зашифрованную информацию, с помощью которой можно восстановить доступ к основному аккаунту в случае утери информации для авторизации
Процесс верификации транзакции
Транзакции, проводимые в нашей системе, проходят в несколько этапов:
1. Инициирование транзакции - посылка в сеть пакета запроса на проведение транзакции
2. Проверка и определение консенсуса по транзакции сетью - запрос подписвается проверяющими и блок записывается в нить блокчейна транзакционного аккаунта
3. Авторизация транзакции с помощью верификационного аккаунта - программное обеспечение, определив, что есть новая транзакция в нити транзакционного аккаунта, информирует владельца и, если владелец подтверждает транзакцию, то в нить транзакционного аккаунта записывается блок верификации транзакции и она считается совершенной. Информация о том, что транзакция авторизована посылается и получателю средств, который формирует блок принятия средств на свой счет.
Ограничения на вывод средств
С помощью определенного вида мета-данных, которые устаналиваются при создании транзакционного аккаунта и не могут быть изменены в последствии, есть возможность создать такой транзакционный аккаунт, на котором лимитирован вывод средств не на уровне программного обеспечения кошелька, а на уровне протокола сети. Например можно ограничить дневной, недельный и т.д. вывод средств с аккаунта, используемого для текущих операций, или же определить период задержки, в течении которого инициированная и авторизованная транзакция может быть отменена, на транзакционном аккаунте, предназначенном для хранения более серьезных средств. Таким образом, взлом кошелька или даже компроментация секретных ключей, не даст злоумышленнику похитить средства, защищенные на уровне протокола сети.
Восстанавление доступа к аккаунту
Для доступа к средствам пользователь использует три фактора авторизации:
1. Приватный ключ основного аккаунта
2. Приватный ключ верификационного аккаунта
3. Парольную фразу
При утере одного из факторов, и при условии, что два оставшихся могут быть использованы пользователем, утерянный фактор может быть заменен на новый при помощи так называемых доверенных аккаунтов. Основная идея состоит опять же в использовании мета-данных - доверенным аккаунтам предоставляется некая одноразовая зашифрованная фраза, которая не может быть расшифрована средствами доверенного аккаунта. Если возникает необходимость заменить один из утерянных факторов авторизации, то пользователь должен сформировать специальную транзакцию с оставшимися средствами авторизации и новым значением утерянного средства авторизации и запрсить у доверенных аккаунтов сформировать и послать транзакцию, верифицирующую производимые изменения в мета-данных "пострадавшего" аккаунта.
Разумеется, что доверенные аккаунты должны быть такими, что владелец основного аккаунта может им доверять, что они откликнуться на просьбу о верификации - или члены семьи, или друзья, или, скажем, специальная организация, предоставляющая подобные услуги если первые два варианта не особенно релевантны.
Изменяемость приватного ключа
В качестве дополнительной меры по защите доступа к средствам пользователя мы сейчас рассматриваем возможность сделать приватный ключ основного аккаунта периодически изменяемым. Данная функциональность нацелена на защиту от того случая, когда аккаунт хранится на некотором веб-портале, например - бирже, и всегда существует риск хищения приватных ключей с такого публичного хранилища. Если после этого злоумышленнику удастся завладеть устройством хранения верификационного аккаунта, то средства могут оказаться уязвимыми.
Чтобы избежать подобного сценария приватный ключ аккаунта можно периодически менять и все входящие транзакции по прежнему смогут проходить со старым ключем, в то время как исходящие только с новым.
Спасибо за внимание! Мнения, критика, предложения более чем приветствуются!
Topic: Использование мета-данных для безопаснос (Read 110 times)
Jump to: