Холодный мультивалютный кошелек на платформе MKT

Р. А. Шарапов

Московский физико-технический институт

Введение

При использовании горячих криптовалютных кошельков из-за постоянного контакта с сетью повышается риск компрометации ключей. Поэтому для более безопасного хранения криптовалюты и совершения транзакций используют холодные криптовалютные кошельки [1].

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

• во-первых, нет гарантии, что операция проводится на доверенном компьютере;
• во-вторых, для выполнения транзакции кошельку необходимо обновить блокчейн, то есть за продолжительное время ему необходимо скачать большой объем информации, и в данных условиях снова повышается риск компрометации ключей, так как за время закачки необходимой информации в систему может попасть вредоносный код.

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

Данное противоречие можно разрешить, если в качестве доверенной исполняемой среды использовать облачный микрокомпьютер с динамически изменяемой архитектурой MKT. Он позволяет размещать ПО в памяти с физически устанавливаемым доступом read-only [2], что исключает его искажение и обеспечивает неизменность среды функционирования.

В настоящей работе предложен концепт решения этой задачи, и рассмотрена реализация локального холодного кошелька на платформе МКТ.

1. Хранение криптовалюты и совершение транзакций

Рассмотрим механизм работы блокчейна и блокчейн транзакций.

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

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

• Криптовалюта — это счетчик, записанный в реестре валют блокчейн программы [3].
• Криптовалюта хранится не в кошельке, а в реестре валюты в блокчейне [3].
• У кого есть закрытый ключ от аккаунта, на котором лежат деньги, тот может переводить деньги в независимости от мнения владельца пары ключей.
• В случае кражи ключей и вывода денег злоумышленника вычислить крайне трудно.
• Для безопасного хранения криптовалюты необходимо хранить в безопасности закрытые ключи.
• Неважно откуда или с какого типа кошелька идет перевод денег. Важно, чтобы программа получила из блокчейна корректную идентификационную информацию [4].
• «Холодный кошелек» означает, что кошелек не требует постоянного подключения к интернету.
• «Горячий» кошелек требует подключения к сети, что делает его более уязвимым для атак, так как каналы связи или сервера могут быть скомпрометированы [1].
• Холодный кошелек является безопасным при условии, что компьютер, на котором хранятся закрытые ключи, является доверенным, и мы можем гарантировать, что у злоумышленников нет к нему доступа.
• Пока не осуществлён ни один платеж с холодного кошелька (ни разу не использован закрытый ключ) — холодный кошелек будет безопасен.
• Проверять получение платежей на свой адрес можно на сторонних сервисах контроля блокчейна, по запросу на открытый ключ пользователя.
• После проведения первой транзакции кошелек перестает быть холодным в чистом виде (из пассивного режима на короткий период переходит в активный). Из-за чего возрастает риск компрометации ключа. Чем больше хранимая сумма — тем больше риск.
• После совершения транзакции и отключения интернета риск компрометации ключа снижается, но все равно остается, так как злоумышленники, применяя аналитические методы и вредоносное программное обеспечение, могут получить доступ к закрытому ключу.
• В большинстве криптовалют действует система транзакций, аналогичная биткойну. Эта система подразумевает, что каждая транзакция должна быть потрачена полностью. То есть если у Алисы на аккаунте есть 5 BTC, и она хочет перевести Бобу 1 BTC, то она должна сделать транзакцию с двумя выходами: один для боба (1 BTC) и второй для «сдачи» на ее собственный адрес (4 BTC) [5].
• Риски после совершения транзакций можно нивелировать, если использовать одноразовые ключевые пары, и после каждой транзакции переводить «сдачу» на свой другой, только что созданный аккаунт. В такой схеме ключевые пары являются одноразовыми и после первой же произведенной транзакции больше не используются.

Снижение риска компрометации закрытых ключей во время соединения с интернетом является основной задачей этой работы.

2. Офлайн подпись транзакций

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

Распишем цикл работы этой системы:

• На первом компьютере создается пара ключей.
• Открытый ключ (адрес) импортируется на второй компьютер. После чего на этот адрес можно перевести необходимую сумму для хранения.
• Когда возникает необходимость в переводе валюты, на втором компьютере создается неподписанная транзакция, в которой указываются адреса отправителя и получателя, а также объём средств.
• Затем неподписанная транзакция с помощью отчуждаемого носителя импортируется на первый компьютер.
• На первом компьютере транзакция подписывается.
• После этого подписанная транзакция с помощью отчуждаемого носителя экспортируется на второй компьютер.
• Транзакция отправляется в сеть.

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

3. Иерархическая генерация ключей

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

Иерархически детерминированный кошелек (Deterministic wallet) — это кошелек, особенность которого состоит в том, что он обеспечивает возможность породить сколько угодно пар ключей для электронной подписи из одного общего секрета (master seed) [6]. Это позволяет использовать новые адреса для каждого входящего платежа и для каждой сдачи. При этом все порожденные из основного секрета закрытые ключи, друг с другом никак не связаны, то есть нельзя проследить связь между порожденными адресами (определить что все они принадлежат одному пользователю), и, имея порожденный закрытый ключ, нельзя восстановить изначальный общий секрет. Стандартизированный подход к кодированию основного секрета расписан в протоколах семейства BIP (Bitcoin Improvement Protocol) [7].

Детерминированные кошельки бывают двух типов:

• Простой детерминированный кошелек. Кошелек напрямую генерирует множество закрытых ключей из master seed. Их количество может быть ограничено только размерностью индекса, который присоединяется к секрету перед хешированием. Обычно это 4 байта, то есть пространство возможных вариантов допускает 2³², то есть около 4 миллиардов уникальных ключей.
• Иерархически детерминированный кошелек (hierarchical deterministic wallets, HD wallets). На каждом уровне иерархии узел порождения имеет три объекта: закрытый ключ (private key), открытый ключ (public key) и код цепочки (chain code), который используется для порождения следующего уровня иерархии. Ключ, из которого порождают, называется родительским (parent), а порожденный ключ называется дочерним (child). Генерации ключей происходит по стандарту BIP32, в котором определены принципы работы этих кошельков [3].

Стоит отметить, что получение из родительского открытого ключа дочернего закрытого невозможно. То есть в данных системах можно выполнить следующие операции по развёртыванию ключа:

• Master seed --> master key
• Private parent key --> private child key
• Private parent key --> public child key
• public parent key --> public child key

Рассмотрим следующий подход — hardened derivation. Это метод, не позволяющий рассчитывать дочерние открытые ключи из соответствующего родительского открытого ключа [7]. В обычном порождении в качестве сообщения функции HMAC используется конкатенация сериализованной точки на эллиптической кривой в качестве родительского открытого ключа, а в hardened derivation используется сериализация родительского закрытого ключа. Если использовать этот подход, то злоумышленник, имея на руках родительский открытый ключ, не сможет рассчитать дочерние открытые ключи, и следовательно, он не сможет вычислить адреса и их связь с полученным родительским ключом, что гарантирует дополнительный уровень анонимности.

Перечислим основные протоколы из семейства BIP, обеспечивающие работу HD Wallet.

• BIP32 (hierarchical deterministic wallets) [8]:

BIP32 — это протокол, определяющий иерархические ключи и способы их внутренней организации в виде древовидной структуры. Так же в этом протоколе расписан способ разделения ключей на те, что будут использоваться для основных транзакций, и на те, что нужны для возвращения сдачи.

• BIP39 (mnemonic code for generating deterministic keys) [9]:

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

• BIP43 (Purpose Field for Deterministic Wallets) [6] и BIP44 (Multi-Account Hierarchy for Deterministic Wallets) [10].

BIP43 предполагает запись в первый уровень иерархии ключа номера улучшения, которое предлагает новый путь порождения или улучшения (m/bip_number’/*). Протокол BIP44 использует особенность предыдущего предложения, то есть для первого уровня иерархии записывается индекс 44, а в индексе второго уровня записывается определенное значение, которое будет соответствовать типу монеты, которую мы используем для данного кошелька. Благодаря этому в одном кошельке могут разворачиваться и использоваться ключи для разных валют, то есть кошелек становится мультивалютным.

Таким образом технология HD Wallet с применением метода hardened derivation позволяет оперировать очень большим (до 4 млрд) количеством аккаунтов в разных блокчейн системах, сохраняя удобство, возможность автоматически посылать сдачу от транзакций на новые адреса, а также полную анонимность платежей. При этом от пользователя требуется всего лишь знать один мастер ключ (или мнемоническую фразу, при использовании стандарта BIP39). Решение является очень удобным для пользователя и эффективным с точки зрения безопасности.

4. МКТ и новая гарвардская архитектура

Вспомним классические подходы при построении архитектуры компьютерных систем:

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

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

Запись в долговременную память можно заблокировать если использовать механизмы контроля целостности данных, при этом проверка целостности должна идти до загрузки операционной системы. То есть атаки можно заблокировать с помощью механизмов контроля запуска задач (процессов, потоков) [13].

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

Эти противоречия разрешает новая гарвардская архитектура – модификация гарвардской архитектуры, с использованием неизменяемой памяти (что избавляет от необходимости использовать сложные механизмы контроля целостности программ и данных до запуска ОС) и блоков сеансовой памяти (для возможности исполнения программ, для большей части из которых необходима возможность записи) [13] [14].

Существует семейство компьютеров с вирусным иммунитетом на базе новой гарвардской архитектуре [12] — компьютеры MKTrusT, которые позволяют работать в одном из двух режимов — защищенном (read only) или незащищенном (read and write) [15]. Работа в этих режимах производится в разных ОС, загружающихся из разных, физически разделенных, разделов памяти. Взаимовлияние ОС друг на друга исключено технологически, как исключен и их одновременный запуск. Переключение режимов работы производится с помощью физического переключателя, расположенного на корпусе устройства. Необходимый режим может выбрать только пользователь. Хакер не может осуществить этот выбор, так как невозможно программное воздействие на выбор режима. Для совершения транзакции пользователю понадобиться выйти в интернет, и в таком случае ОС может перестать быть доверенной. Поэтому выход в интернет осуществляется только со второй незащищенной ОС.

5. Использование особенностей МКТ для устранения известных уязвимостей

Перечисленные выше ключевые особенности МКТ позволяют решить ряд проблем при работе с криптовалютными кошельками:

1. Офлайн подпись транзакций. Если в качестве офлайн компьютера использовать МКТ в защищенном read only режиме, то можно гарантировать, что даже при попадании вредоносного ПО в систему, оно не сможет исполниться, и транзакция не будет скомпрометирована.
2. Использование U2F устройств для подписи транзакций. Используя защищенную ОС МКТ в качестве доверенной среды, мы можем быть уверены, что на входе и выходе U2F устройства будет именно та транзакция, которая нам нужна.
3. Хранение ключей. Если устанавливать кошелек в защищенную ОС МКТ, то при создании ключевой пары в этом кошельке можно выбрать опцию сохранения закрытого ключа в постоянную память. При этом ключи не будут скомпрометированы.

Кроме того особенности архитектуры МКТ позволяют исполнять часть функционала кошелька в защищенной среде, и часть — в не защищенной. Чтобы эффективно использовать эту опцию, необходимо понять, какую часть функционала кошелька необходимо исполнять в каждой из ОС. Для этого введем два класса операций:

1. Операции, которые необходимо проводить в защищенной (RO) ОС
2. Операции, которые необходимо проводить в незащищенной (RW) ОС

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

Ко второму классу отнесем те функции, для исполнения которых необходима запись данных в постоянную память (так как в этом классе применяется read and write ОС), а также необходим интернет (соединение с которым повышает вероятность атаки на систему, а поэтому не желательно оперировать ценными данными в этой ОС).

Проведем следующий анализ функционала:

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

Результаты анализа занесем в таблицу 1

Таблица. 1 Сравнительный анализ функционала кошелька

Название функции	Описание	Есть ли потенциальные уязвимости?	Класс функции
Генерация ключей, мастер ключа или мнемонической фразы	Генератор псевдослучайных чисел выдает на выходе либо ключевую пару, либо master seed, из которого дальше по протоколу BIP32 будут развернуты остальные ключевые пары. По протоколу BIP39 этот master seed будет представлен в виде мнемонической фразы.	Если среда и приложение доверенные — то нет.	Класс 1
Развертывание ключей из мастер ключа или мнемонической фразы	Пользователь вводит ключ или мнемоническую фразу, а кошелек на основе введеных данных выдает список всех ключевых пар пользователя, после чего ими можно пользоваться.	Если среда и приложение доверенные — то нет.	Класс 1
Создание нового аккаунта в кошельке	После генерации и развертывания ключей будет создан файл аккаунта в кошельке. В этом файле будет записано, что за данным пользователем закреплены соответствующие открытые ключи. Этот же файл будет хранить историю операций.	Хранить историю операций и открытые ключи в постоянной памяти компьютера — это потенциально небезопасное решение. Если среда недоверенная, то при компрометации такого файла злоумышленник может узнать, что определенный набор открытых ключей принадлежит одному человеку.	Класс 1
Чтение баланса из скачанного блокчейна	Идет чтение из блокчейна, расположенного в постоянной памяти. По завершении операции на выходе получаем баланс адреса на момент последнего обновления блокчейна.	Если исключить вероятность наличия вредоносного кода в скачанном блокчейне, то сама операция чтения не является уязвимой	Класс 2
Скачивание обновление блокчейна	Обновление блокчейна для последующего совершения транзакции или чтения баланса аккаунта.	Из интернета в течении продолжительного времени скачивается большой объем данных (в случае, если блокчейн не обновлялся достаточно давно), поэтому есть вероятность скачивания вредоносного кода.	Класс 2
Чтение баланса из блокчейна в интернете	Чтобы не скачивать гигабайты данных, идет чтение из блокчейна, расположенного в интернете, то есть идет обращение к серверам или соседним узлам. По завершении операции на выходе получаем баланс аккаунта на момент последнего обновления блокчейна.	За время соединения с интернетом в систему может попасть вредоносный код. Также есть вероятность чтения данных из ложных источников в случае компрометации каналов связи.	Класс 2
Создание транзакции	Пользователь вводит адрес отправителя, адрес получателя и количество валюты которую нужно перевести. В случае, если сумма переводится не полностью, то необходимо добавить адрес для возвращения сдачи. Также в транзакцию необходимо добавить ряд служебной информации, включая адреса и хэши транзакций, с которых были получены средства, для корректной работы этого этапа, необходимо обновить блокчейн до актуального состояния. На выходе получаем сформированную, но не подписанную транзакцию.	Есть возможность того, что злоумышленник может подменить данные в транзакции на ложные. Учитывая что перед этим этапом, был этап обновления блокчейна, то в системе мог оказаться вредоносный код.	Класс 2
Подпись транзакции через интерфейс кошелька	Чтобы подписать транзакцию, пользователю необходимо ввести закрытый ключ в соответствующее поле или произвести чтение из файла, в котором в зашифрованном виде хранятся закрытые ключи. После чего система произведет все необходимые операции и вычисления.	Подмена транзакции на ложные данные. Компрометация закрытого ключа.	Класс 1
Трансляция транзакции в блокчейн сеть	Подписанная транзакция посылается в сеть на ближайший доступный узел.	Злоумышленник может послать в сеть подписанную в предыдущем пункте транзакцию с ложными данными. Остальные атаки зависят от надежности канала связи и узлов, на которые идет распространение информации	Класс 2
Аутентификация через U2F	В случае если был создан кошелек с двухфакторной аутентификацией, то для входа в свой аккаунт пользователь должен вставить в компьютер U2F устройство.	Если среда и приложение доверенные, то нет.	Класс 1
Подпись транзакции через U2F	На вход в U2F устройство посылается не подписанная транзакция. U2F устройство посылает в компьютер подписанную транзакцию.	На вход устройству может послаться транзакция с фальшивыми данными или с вредоносным кодом.	Класс 1
Хранение ключей	Закрытые ключи хранятся на жестком диске в зашифрованном виде.	Ключи лучше не хранить в постоянной памяти, но если возникает такая необходимость, то делать это можно только в защищенной ОС.	Класс 1

Перечислим все операции необходимые для работы проектируемой системы, на эти два класса:

• Операции, которые необходимо проводить в защищенной (RO) ОС:
  • Генерация ключей, мастер ключа или мнемонической фразы.
  • Развертывание ключей из мастер ключа или мнемонической фразы.
  • Создание нового аккаунта в кошельке.
  • Подпись транзакции через интерфейс кошелька.
  • Подпись транзакции через U2F.
  • Хранение ключей в постоянной памяти.
  • Аутентификация через U2F.
• Операции, которые необходимо проводить в не защищенной (RW) ОС:
  • Чтение баланса из скачанного блокчейна.
  • Скачивание и обновление блокчейна.
  • Чтение баланса из блокчейна в интернете.
  • Создание транзакции.
  • Трансляция транзакции в блокчейн сеть.

Выполнение этих операций в соответствующих ОС поможет минимизировать риски компрометации.

6. Сценарий работы системы

Опишем работу системы на логическом уровне.

Начало работы с мультивалютным кошельком выглядит следующим образом:

• Заходим в защищенную ОС и создаем кошелек.
• Импортируем необходимые открытые ключи для последующего применения в незащищенной ОС.
• Заходим в незащищенную ОС и импортируем созданные в предыдущем пункте открытые ключи в кошелек
• Когда возникает необходимость совершить транзакцию с одного из адресов, то система в незащищенной ОС должна:
  • Обновить блокчейн.
  • Сформировать транзакцию.
  • Экспортировать сформированную транзакцию на отчуждаемый носитель.
• Сформированная в предыдущем пункте транзакция на отчуждаемом носителе импортируется в защищенную ОС.
• В защищенной ОС транзакция подписывается с помощью одного из вариантов:
  • С помощью U2F устройства.
  • С помощью закрытого ключа, который хранится в зашифрованном виде в файле в постоянной памяти.
  • С помощью закрытого ключа, введенного пользователем вручную в соответствующее поле интерфейса.
• После этого подписанная транзакция экспортируется через отчуждаемый носитель обратно в незащищенную ОС.
• В незащищенной ОС подписанная транзакция транслируется в сеть.

Схема рабочего цикла кошелька приведена на рис. 1

Рис. 1. Схема работы проектируемой системы

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

Заключение

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

Список литературы:

1. Cold storage [Электронный ресурс] /. — Электрон. текстовые дан. — Режим доступа: https://en.bitcoinwiki.org/wiki/Cold_storage, свободный (дата обращения 20.06.19)
2. Конявский, В.А. Компьютер с «вирусным иммунитетом» [Электронный ресурс] / В.А. Конявский. — Электрон. текстовые дан. — Режим доступа: http://www.okbsapr.ru/konyavskiy_2015_2.html, свободный (дата обращения 20.06.19)
3. Bitcoin in a nutshell — Blockchain [Электронный ресурс] /. — Электрон. журн. — Режим доступа: https://habr.com/ru/post/320176/ (дата обращения 20.06.19)
4. Как на самом деле работает протокол Биткоин [Электронный ресурс] /. — Электрон. журн. — Режим доступа: https://habr.com/ru/post/222493/ (дата обращения 20.06.19)
5. Bitcoin: A Peer-to-Peer Electronic Cash System [Электронный ресурс] / Satoshi Nakamoto. — Электрон. журн. — Режим доступа: https://bitcoin.org/bitcoin.pdf(дата обращения 20.06.19)
6. Hierarchical deterministic Bitcoin wallets that tolerate key leakage [Электронный ресурс] / Gus Gutoski. — Электрон. журн. — Режим доступа: https://eprint.iacr.org/2014/998.pdf(дата обращения 20.06.19)
7. Иерархическая генерация ключей [Электронный ресурс] /. — Электрон. текстовые дан. — Режим доступа: https://habr.com/company/distributedlab/blog/413627/, свободный(дата обращения 20.06.19)
8. bip-0032 [Электронный ресурс] /. — Электрон. текстовые дан. — Режим доступа: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki, свободный(дата обращения 20.06.19)
9. bip-0039 [Электронный ресурс] /. — Электрон. текстовые дан. — Режим доступа: https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki, свободный(дата обращения 20.06.19)
10. bip-0043 [Электронный ресурс] /. — Электрон. текстовые дан. — Режим доступа: https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki, свободный (дата обращения 20.06.19)
11. bip-0044 [Электронный ресурс] /. — Электрон. текстовые дан. — Режим доступа: https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki, свободный(дата обращения 20.06.19)
12. Конявский В. А. Компьютер с вирусным иммунитетом // Информационные ресурсы России. 2015. № 6. С. 31–34.(дата обращения 20.06.19)
13. Конявский В. А. Мобильный компьютер с аппаратной защитой доверенной операционной системы: Патент на полезную модель № 147527. 10.11.2014. Бюл. № 31.(дата обращения 20.06.19)
14. Конявский В. А. Защищенный микрокомпьютер МК-TRUST — новое решение для ДБО // Национальный банковский журнал. — 2014. — № 3. — С. 105.(дата обращения 20.06.19)
15. Работа с одного рабочего места в двух разных контурах защищенности [Электронный ресурс] /. — Электрон. текстовые дан. — Режим доступа: http://www.okbsapr.ru/sol17.html, свободный (дата обращения 20.06.19)

Автор: Шарапов Р. А.

Дата публикации: 18.01.2019

Библиографическая ссылка: Шарапов Р. А. Холодный мультивалютный кошелек на платформе MKT // Безопасность информационных технологий = IT Security. М., 2019. Том 26. № 3. С. 32–44.

---