Автоматическая аттестация сохранности устройства с применением цепочки блоков

Изобретение относится к области кибербезопасности. Технический результат заключается в обеспечении защищенности книги учета транзакций. Реализуемый на компьютере способ проверки сохранности устройства пользователя в коммуникационной сети цепочки блоков, включающий при подготовке к доставке электронной транзакции в сети цепочки блоков реализацию процесса проверки сохранности устройства в качестве части транзакции, включающую выполнение внутреннего подтверждения сохранности среды выполнения устройства из корня доверия в устройстве пользователя и затребование электронной подписи, таким образом проверку сохранности подписи применяют к транзакции цепочки блоков, причем проверка сохранности подписи основана на определении того, находится ли среда выполнения устройства в известном хорошем состоянии, при этом на основе сохранности подписи обеспечивают разрешение на продолжение транзакции или запрос восстановительному уполномоченному субъекту на проверку того, что электронную транзакцию, предусмотренную пользователем, разрешено продолжать, даже при определении того, что среда выполнения устройства не находится в известном хорошем состоянии. 2 н. и 15 з.п. ф-лы, 8 ил., 23 табл.

 

РОДСТВЕННАЯ ЗАЯВКА

[0001] Эта заявка испрашивает приоритет предварительной заявки на патент США №62/136340, поданной 20 марта 2015 г., и предварительной заявки на патент США №62/136385, поданной 20 марта 2015 г. Все принципы вышеуказанных заявок включены в данный документ посредством ссылки. ОБЛАСТЬ ТЕХНИКИ

[0002] Настоящее изобретение в общем относится к области кибербезопасности. В частности, настоящее изобретение относится к устройствам обеспечения безопасности посредством проверки состояния и/или целостности устройств для выполнения транзакций по компьютерной сети.

уровень техники

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

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

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

[0005] Большинство транзакций, фиксируемых в цепочке блоков Bitcoin, записывают передачу ценности от одного человека другому. Открытые ключи представляют вовлеченные стороны. Соответствующие закрытые ключи позволяют участнику запрашивать результат. Поскольку другого способа надзора или контроля не существует, очевидно, что закрытый ключ должен быть защищен. Цепочка блоков является неосязаемой структурой. Люди могут взаимодействовать с ней только посредством своего контроля над подключенным к сети устройством. В общих чертах имеется три способа осуществления этого. A) Человек управляет машиной, которая сама является одноранговым узлом и осуществляет запись непосредственно в цепочку блоков. B) Человек использует веб-сайт или мобильное приложение для передачи команд на сервер, действующий от его имени, или C) человек использует веб-сайт или приложение для распространения транзакции, которая сформирована локально.

[0006] Как правило, для подписи запроса применяется закрытый ключ. Среда выполнения несет ответственность за точность запроса и защиту закрытого ключа. Аттестация состояния и происхождения среды выполнения определяет ее надежность.

[0007] Существует ряд широко распространенных средств, которые могут применяться для улучшения безопасности среды выполнения. Они варьируются от идентификатора устройства на аппаратной основе до сред выполнения с полным доверием. Сеть потребителей является наиболее широко распространенной платформой обслуживания, которая основана не на идентификации устройств, а на способах идентификации пользователей. В отличие, например, от мобильной телефонии или кабельного телевидения, где аутентификация услуги производится разрешающим устройством, сеть требует, чтобы конечные пользователи выполняли протокол идентификации, т.е. вводили имя пользователя и пароль. Хотя имеются преимущества, связанные с переносимостью этого способа, на практике он является опасно уязвимым. Пользователи очень плохо запоминают сложные пароли и раздражаются из-за постоянных запросов. В результате появляются такие пароли как «ВпередДинамо» и ключи сеанса, существование которых обеспечено долгим. С другой стороны устройство благополучно будет проходить криптографическую аутентификацию, намного превышающую возможности любого человека с любыми из тысяч удостоверяющих данных, хранимых на его аппаратном обеспечении. И оно будет делать это снова и снова без остановки.

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

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

[0010] Пользователь часто не знает, нарушена ли безопасность его устройства, но если можно обнаружить, например, изменения в BIOS, то услуга может предпринять меры предосторожности.

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

[0012] В цепочку снабжения проложили себе путь решения по поддержке безопасности устройств основанные как на закрытом коде, так и на стандартах. К примеру, модуль доверенной платформы (TPM), представляет собой микросхему безопасности, встроенную в материнскую плату большинства современных персональных компьютеров. Технология определяется группой доверенных вычислений (TCG), неприбыльным объединением десятков основных поставщиков. Она была разработана в значительной мере для поддержки безопасности сетей масштаба предприятия, но может играть большую роль в упрощении сети потребителей. TPM отпускается в течение полудюжины лет и теперь является значительно преобладающим в современных персональных компьютерах. Совместимость с логотипом Майкрософт, которая имеет место с 2015 г., будет дополнительно гарантировать, что никакая машина не поставляется без TPM.

[0013] TPM является относительно простым. Он служит для трех основных целей: PKI, сохранности BIOS и шифрования. Хотя технологию развивают уже более десяти лет, устройства с поддержкой TEE стали доступны лишь недавно. Intel начала поставки коммерческих решений в 2011 г., и Trustonic начала свою деятельность в 2013 г. Платформы и связанные инструменты достигают уровня зрелости, требуемого для потребительского использования. Разворачивание приложения в TEE похоже на поставку специализированного аппаратного устройства. Выполнение и данные криптографически изолированы от любой другой функции вмещающего устройства.

[0014] Микросхема не имеет своего собственного идентификатора, но у нее можно запросить сгенерировать пары ключей. Ключи аттестации идентификатора (AIK) могут быть обозначены как «непереносимые», таким образом закрытая половина пары ключей никогда не будет видима вне аппаратного обеспечения. Это предоставляет возможность установить идентификатор устройства, для которого нельзя создать абсолютную копию. Поставляемый в настоящее время TPM версии 1.2 ограничен RSA и SHA-1. Выходящая вскоре версия 2.0 будет намного более гибкой. TPM также реализует ключ подтверждения (EK). EK устанавливается во время производства и может быть использован для подтверждения того, что TPM действительно является реальным TPM. Система, поддерживающая TPM, загружает регистры конфигурации платформы (PCR) во время своей последовательности загрузки. Начиная с программно-аппаратного обеспечения, каждый этап в процессе загрузки измеряет свое состояние и состояние следующего процесса и записывает PCR-значение. Поскольку регистры PCR фиксируются в устойчивом ко взлому TPM, в последствии можно запросить надежный «снимок» сохранности системы BIOS. PCR не фиксирует того, что фактически произошло, а лишь посредством последовательности хешей фиксирует, что ничего не изменилось. Это особенно важно для защиты от наиболее серьезных и другим способом необнаруживаемых атак, при которых взломщик нарушает безопасность устройства BIOS или устанавливает тайный гипервизор. В сочетании с подтверждающей подписью от антивирусного программного обеспечения можно установить надежное состояние машины. TPM также обеспечивают услуги шифрования в больших объемах. Ключи шифрования генерируются в TPM, но не хранятся там. Вместо этого они шифруются с использованием связанного с TPM корневого ключа хранилища и возвращаются в запрашивающий процесс. Процесс, который желает зашифровать или расшифровать двоичный объект данных, сначала устанавливает желаемый ключ. Затем ключ расшифровывается в аппаратном обеспечении и делается доступным для шифрования. Как и большинство ключей TPM, ключи шифрования могут быть дополнительно защищены паролем, если необходимо.

[0015] Trustonic (http://www.trustonic.com) - это совместное предприятие ARM, G+D и Gemalto. Trustonic предоставляет доверенные среды выполнения для широкого ряда умных устройств. Цель состоит в обеспечении безопасного выполнения особо важных программных услуг. Trustonic представляет собой реализацию стандарта Global Platform для доверенных сред выполнения. Приложения, написанные для выполнения в Trustonic TEE, подписывают и измеряют. Устройства, поддерживающие «Trustonic», предоставляют изолированное ядро выполнения, так что загруженное приложение нельзя отследить никаким другим процессом, работающим на устройстве, включая операции отладки на устройстве с правами администратора. Trustonic была сформирована в 2012 г. и в настоящее время осуществляет поставки с полудюжиной производителей и поддерживает пару дюжин поставщиков услуг. С поддержкой Trustonic уже поставлено более 200 миллионов устройств.

[0016] Intel vPro представляет собой собрание технологий, встроенных в современный набор интегральных схем «Intel». Новые машины со знаком «vPro» поддерживают технологию доверенного выполнения Intel (TXT). Intel предлагает среду безопасной обработки в машине управления (ME), которая обеспечивает защищенное выполнение многочисленных криптографических функций. Одним вариантом применения этой функциональной возможности является разворачивание функций TPM 2.0, реализованных в виде приложения в ME. Машина управления также поддерживает функции безопасного отображения для проведения полностью изолированных сеансов связи с пользователем. Таким образом приложение, выполняющееся в ME, может получать указания от пользователя с существенно меньшим риском нарушения безопасности.

[0017] Технология ARM TrustZone предоставляет кремниевую основу, которая доступна на всех процессорах ARM. Примитивы изолируют защищенную среду выполнения от общего пространства выполнения. ARM предоставляет схемы, которые затем встраивают в ряд стандартных процессоров. Для использования преимуществ TrustZone приложения могут или быть развернуты в качестве части системного аппаратно-программного обеспечения производителем, или могут быть предоставлены после этого посредством инструментов третьих сторон, таких как микроядро с открытым исходным кодом Trustonic, Linaro или Nvidia.

[0018] Некоторые варианты настоящего изобретения применяют эти технологии в наборе услуг для усовершенствования среды транзакций, которая связывает людей и цепочку блоков.

[0019] Концепция двухфакторной аутентификации является хорошо разработанной, хотя и имеющей ограниченное применение. Вероятно, наиболее значительно она используется сайтами для работы с Bitcoin, где раскрытие имени пользователя может привести к немедленной и невосстановимой краже средств. Большинство людей знакомы со вторым фактором в форме подтверждения по SMS или брелока. Вы вводите свое имя пользователя и пароль и затем вводите код, переданный в сообщении на ваш зарегистрированный телефон. Двухфакторная аутентификация является важным этапом для безопасности входа в систему, однако она нагружает пользователя дополнительной работой. Даже если мы понимаем, почему это важно, человек по своей природе ленив. Многие сайты предлагают пользователям отказаться от повторяющихся подтверждений, и многие пользователи с готовностью соглашаются на это сберегающее время ухудшение безопасности. Дополнительный иллюстративный способ может заключаться в первоначальном подтверждении подлинности устройства, с которого отправлен запрос аутентификации. Используя TPM или любой другой безопасный источник наборов криптографических ключей, веб-сервис может попросить устройство доказать, что оно является тем же устройством, что было раньше. Этот запрос может быть прозрачным для пользователя (или дополнительно защищен посредством PIN) и обеспечивает уровень подтверждения, при помощи которого часто можно обойтись без надоедливых запросов к пользователю на проверку личности и аутентификацию.

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

[0021] Согласно одному иллюстративному варианту осуществления настоящего изобретения первый этап выполнения идентификации устройства представляет собой регистрацию. В одном предпочтительном варианте осуществления регистрация устройства может быть осуществлена под надзором некоторого другого доверенного субъекта. Например, регистрация телефона может происходить в точке продажи, где привязка между конечным пользователем и идентификатором устройства может быть установлена посредством физического присутствия. Однако во многих случаях применения этот уровень связи человека с устройством не является ни необходимым, ни желательным. Идентификатор устройства и признаки, которые можно было бы рассматривать как личную идентификационную информацию (PII), не следует тесно связывать. Простейший идентификатор устройства является полностью анонимным. Для надежной регистрации устройства необходимо лишь две вещи: A) возможность сгенерировать пару ключей, которая привязана к устройству, и B) подтверждение происхождения и качества среды устройства, которая предоставляет эту услугу. Последнее обеспечивается либо социальной инженерией, либо криптографией цепочки снабжения. Хотя ничего нельзя исключать, но устройство, зарегистрированное в присутствии имеющего уважение поставщика, с большой вероятностью будет настоящим устройством. Это является важным для долгосрочной репутации этого поставщика. Доверие к устройству, которое снабжено ключом на сборочной площадке и может быть подтверждено уполномоченным субъектом с сертификатом изготовителя комплектного оборудования, также основано на репутации этого производителя.

[0022] Согласно некоторым вариантам осуществления регистрация включает установление уникальности, которую можно запросить, но не сымитировать. Для этого может быть использован TPM (или подобный аппаратный корень доверия). Микросхема TPM генерирует пару ключей и возвращает открытую часть ключа клиенту, который в свою очередь размещает ее на сервере. Генерируется случайный id, и вместе пара передается в Namecoin (или подобную цепочку блоков, или метод цепочки блоков, предназначенные для записи именованных данных). После размещения в цепочке блоков запись об устройстве может быть расширена и модифицирована такими атрибутами, как снимки PCR, связанные счета Bitcoin, или другими данными. Ожидается, что ссылки на большие объекты данных в цепочке блоков будут производиться не прямо, а посредством хэша и URL. Агент регистрации совместно с устройством контролирует счет Namecoin, который может обновлять эту запись. Однако можно представить сценарий для устройств, проводящих самостоятельную регистрацию, когда устройство также является и агентом регистрации. После регистрации сервис может осуществлять доступ к открытым ключам устройства для подтверждения подлинности и шифрования сообщений и криптографического подтверждения того, что связанные атрибуты происходят от устройства.

[0023] В доверенной среде выполнения предоставляются признаки идентификатора устройства с дополнительным расширением возможности выполнения кода изолированно от остальной части системы. В вариантах осуществления настоящего изобретения предусмотрен компонент услуг Bitcoin, который упакован для разворачивания в различных средах TEE. Это приводит к ряду важных усовершенствований при выполнении транзакции: (1) Код подписывается и аутентифицируется диспетчером доверенных приложений от третьей стороны, так что его невозможно исказить. (2) Код выполняется вне рабочей хост-среды и таким образом защищен от вредоносного программного обеспечения. (3) Данные приложения, за исключением одних ключей, никогда не демонстрируются за пределами TEE.

[0024] Зарегистрированное устройство может создавать запись атрибутов, которые позволяют поставщикам услуг проверять его состояние и контекст. Для того чтобы быть полезными, атрибутам устройства не нужно содержать никакую PII. Например, недавнее сообщение, указывающее на чистую последовательность загрузки, может придать поставщику услуг некоторую уверенность в том, что безопасность машины не нарушена. Атрибуты, которые предоставляют единственное утверждение о факте, также могут быть полезными без разглашения большого объема PII, например, оператор машины был подтвержден как имеющий возраст более 21 года, или как гражданин Франции, или член клуба по интересам. В большинстве случаев взаимодействие с устройством представляет возможность для получения сообщения о сохранности его загрузки. Это ничто более как собрание хэшей, которые могут быть сравнены с сообщением о последней загрузке. Машина, которая загрузилась предсказуемым образом, очевидно является более надежной, чем та, на которой поменялись BIOS или OS. В дополнение к снимкам PCR принимающее участие в процессе антивирусное программное обеспечение может предоставить сообщение о том, что на момент последнего сканирования машина была чистой.

[0025] В некоторых вариантах осуществления интеграция принципов доверенного сетевого соединения (TNC) позволяет производить полное подтверждение подлинности неизвестного клиентского устройства до одобрения транзакции. Нахождение клиентского устройства в известном хорошем состоянии или положении перед одобрением транзакции основано на сообщении третьей стороны о том, что устройство сконфигурировано правильно. Такой тип проверки относится к широкому ряду средств кибербезопасности, которые могут предпочтительно требоваться в качестве части любой системы обработки транзакций.

[0026] Один иллюстративный вариант осуществления представляет собой реализуемый на компьютере способ проверки сохранности устройства пользователя в коммуникационной сети цепочки блоков, включающий при подготовке к доставке электронной транзакции в сети цепочки блоков реализацию процесса проверки сохранности устройства в качестве части транзакции, включающую выполнение внутреннего подтверждения сохранности среды выполнения устройства из корня доверия в устройстве пользователя и затребование электронной подписи, таким образом проверку сохранности подписи применяют к транзакции цепочки блоков; причем проверка сохранности подписи основана на определении того, находится ли среда выполнения устройства в известном хорошем состоянии, при этом на основе сохранности подписи обеспечивают разрешение на продолжение транзакции или запрос у восстановительного уполномоченного субъекта на проверку того, что электронную транзакцию, предусмотренную пользователем, разрешено продолжать, даже при определении того, что среда выполнения устройства не находится в известном хорошем состоянии. В некоторых вариантах осуществления проверка сохранности подписи включает передачу команды корня доверия в сеть цепочки блоков для обработки, таким образом по меньшей мере часть сети цепочки блоков отвечает затребованием нескольких электронных подписей с целью приема электронной транзакции, включающую создание в пределах среды выполнения устройства команды от корня доверия в устройстве пользователя; затребование первой электронной подписи, которая соответствует команде корня доверия, таким образом проверку сохранности подписи применяют к транзакции цепочки блоков; и реагирование на первую электронную подпись посредством проверки сохранности подписи на основе определения того, находится ли среда выполнения устройства в известном хорошем состоянии, включающей сравнение подписи с ранее записанным опорным значением; если подпись соответствует ранее записанному опорному значению - предоставление разрешения на продолжение транзакции; и если подпись не соответствует ранее записанному опорному значению - запрос внешнего процесса третьей стороны на проверку того, что электронную транзакцию, предусмотренную пользователем, разрешено продолжать, даже при определении того, что среда выполнения устройства не находится в известном хорошем состоянии. В некоторых вариантах осуществления проверка сохранности подписи включает предоставление устройством электронной подписи на основе определения того, находится ли среда выполнения устройства в известном хорошем состоянии; предоставление разрешения на продолжение транзакции, если устройство предоставляет электронную подпись; предоставление разрешения на продолжение транзакции, предусмотренной пользователем, даже при определении того, что среда выполнения устройства не находится в известном хорошем состоянии, если восстановительный уполномоченный субъект предоставляет подпись. Дополнительно внешний процесс может также включать применение функции N или M криптографических ключей для подтверждения по меньшей мере одного из следующего: намерение пользователя соответствует предопределенным требованиям, или сохранность устройства соответствует предопределенным требованиям, или дополнительный процесс соответствует предопределенным требованиям. Опорное значение может быть сгенерировано во время процесса регистрации, выполняемого владельцем платформы устройства. Опорное значение может быть сгенерировано на основе сертификата выпуска, приписанного устройству, причем сертификат выпуска генерируется производителем или создателем устройства, производителем или создателем среды выполнения устройства и/или производителем или создателем приложения, находящегося на устройстве. Опорное значение может содержать подпись по меньшей мере одного производителя или создателя устройства, производителя или создателя среды выполнения устройства и/или производителя или создателя приложения, находящегося на устройстве. Внешний процесс третьей стороны может возвращать маркер в ответ на запрос подтверждения транзакции. В некоторых вариантах осуществления может быть предоставлено разрешение на выполнение электронной транзакции в течение определенного периода времени, если подпись не соответствует ранее записанному опорному значению.

В некоторых вариантах осуществления может быть осуществлена проверка того, что задуманную электронную транзакцию разрешено продолжать, даже при определении того, что среда выполнения устройства не находится в известном хорошем состоянии, на основе периода времени между регистрацией опорного значения и транзакции и/или суммы транзакции. Транзакции выше пороговой суммы могут разрешать выполнять, если период времени соответствует предопределенным требованиям. Разрешение транзакции выше определенной суммы может быть основано на минимальном количестве ранее разрешенных транзакций. Некоторые варианты осуществления могут дополнительно включать применение устройства отображения, указывающего пользователю на соответствие сохранности устройства минимальным предопределенным требованиям, и дополнительные действия, которые необходимо предпринять. Другие варианты осуществления могут дополнительно включать уведомление третьей стороне о транзакции, причем в ответ на уведомление третья сторона записывает транзакцию и состояние устройства. Третья сторона может записывать значения измерения, связанные с сохранностью устройства, для будущего анализа транзакции. В дополнение гарантирование приватности записи может включать криптографическое запутывание записи таким образом, что запись делается доступной только для авторизованных третьих сторон. Другой иллюстративный вариант осуществления представляет собой реализуемую на компьютере систему проверки сохранности устройства пользователя в коммуникационной сети цепочки блоков, содержащую коммуникационную сеть цепочки блоков; устройство пользователя в сети цепочки блоков; электронную транзакцию в сети цепочки блоков; процесс проверки устройства, реализованный в качестве части транзакции при подготовке к доставке электронной транзакции в сети цепочки блоков, при этом реализация дополнительно включает внутреннее подтверждение сохранности среды выполнения устройства, выполненное из корня доверия в устройстве; электронную подпись, таким образом проверку сохранности подписи применяют к транзакции цепочки блоков; причем проверка сохранности подписи основана на определении того, находится ли среда выполнения устройства в известном хорошем состоянии, при этом: на основе сохранности подписи обеспечивают разрешение на продолжение транзакции или запрос восстановительному уполномоченному субъекту на проверку того, что электронную транзакцию, предусмотренную пользователем, разрешено продолжать, даже при определении того, что среда выполнения устройства не находится в известном хорошем состоянии.

КРАТКОЕ ОПИСАНИЕ ГРАФИЧЕСКИХ МАТЕРИАЛОВ

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

[0028] Фиг. 1A представляет собой пример цифровой среды обработки, в которой могут быть реализованы варианты осуществления настоящего изобретения.

[0029] Фиг. 1B представляет собой структурную схему любой внутренней структуры компьютера/компьютерного узла.

[0030] Фиг. 2A представляет собой структурную схему, демонстрирующую один пример системы аутентификации устройств согласно настоящему изобретению.

[0031] Фиг. 2B представляет собой схему, демонстрирующую один пример системы аутентификации устройств согласно настоящему изобретению.

[0032] Фиг. 2C представляет собой схему компонентов одного варианта осуществления настоящего изобретения.

[0033] Фиг. 2D представляет собой схему адаптера системы аутентификации и его внешних и внутренних интерфейсов.

[0034] Фиг. 3A представляет собой схему последовательности упаковки и доставки команды кодировщиком.

[0035] Фиг. 3B представляет собой схему процесса регистрации устройств согласно одному варианту осуществления настоящего изобретения.

ПОДРОБНОЕ ОПИСАНИЕ

[0036] Далее следует описание иллюстративных вариантов осуществления настоящего изобретения.

[0037] Варианты осуществления настоящего изобретения представляют собой системы и способы аттестации состояния устройства перед задействованием в электронных транзакциях.

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

[0039] Иллюстративные варианты осуществления могут быть основаны на принципах стандартов доверенного сетевого соединения (TNC), согласно которым сохранность устройства может быть проверена перед фактическим разрешением подключения к коммутатору сети. В соответствии с TNC устройство выполняет ряд измерений, которые безопасно сохраняют на устройстве. Измерения, как правило, включают подтверждение подлинности образа BIOS, операционной системы (OS) и любых приложений, которые необходимо проверить на то, что они не были изменены. После подключения к сети коммутатор выполняет процесс подтверждения подлинности, проверяя, что данные измерений соответствуют опорному значению, которое было вычислено, когда устройство или было подключено ранее, или было в текущем известном хорошем состоянии или положении. Доверенная среда выполнения (TEE) также имеет возможность выполнения процессов самоизмерения и удаленной аттестации состояния устройства. В некоторых предпочтительных вариантах осуществления система TNC основана на стандартах группы доверенных вычислений (TCG) и, как правило, интегрирует микросхему модуля доверенной платформы (TPM).

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

[0041] Цифровая среда обработки

[0042] Один иллюстративный вариант реализации системы согласно настоящему изобретению для аттестации состояния устройства перед задействованием в транзакциях 100 может быть реализован в программной, аппаратно-программной или аппаратной среде. Фиг. 1A представляет собой один пример такой цифровой среды обработки, в которой могут быть реализованы варианты осуществления настоящего изобретения. Клиентские компьютеры/устройства 150 и серверные компьютеры/устройства 160 (или облачная сеть 170) предоставляют устройства обработки, хранения и ввода/вывода, выполняющие прикладные программы, и т.п.

[0043] Клиентские компьютеры/устройства 150 могут быть связаны прямо или посредством коммуникационной сети 170 с другими вычислительными устройствами, включая другие клиентские компьютеры/устройства 150 и серверные компьютеры/устройства 160. Коммуникационная сеть 170 может быть частью беспроводной или проводной сети, сети удаленного доступа, глобальной сети (т.е. Интернет), объединения компьютеров по всему миру, локальной или региональной сетей, шлюзов, маршрутизаторов и коммутаторов, которые для осуществления связи друг с другом в настоящее время используют разнообразные протоколы (например, TCP/IP, Bluetooth®, RTM и т.п.). Коммуникационная сеть 170 может также представлять собой виртуальную частную сеть (VPN) или выделенную сеть, или обе. Коммуникационная сеть 170 может иметь различные формы, включая, но без ограничения, сеть передачи данных, сеть передачи голоса (например, наземную линию, мобильную и т.п.), сеть передачи аудио, сеть передачи видео, спутниковую сеть, радио сеть и пейджерную сеть. Также применимы и другие архитектуры электронных устройств/компьютерных сетей.

[0044] Серверные компьютеры 160 могут быть сконфигурированы для предоставления системы 100 аутентификации устройств пользователя, которая осуществляет связь с субъектами аутентификации для подтверждения подлинности запросчика перед тем, как позволить запросчику осуществить доступ к ресурсам, защищенным системой аутентификации. Серверные компьютеры могут быть не отдельными серверными компьютерами, а частью облачной сети 170.

[0045] Фиг. 1B представляет собой структурную схему любой внутренней структуры компьютера/компьютерного узла (например, клиентского процессора/устройства 150 или серверных компьютеров 160) в среде обработки, представленной на фиг. 1A, которая может быть использована для облегчения отображения информации, связанной с аудио, изображениями, видео или сигналами данных. Каждый компьютер 150, 160, представленный на фиг. 1B, содержит системную шину 110, причем шина представляет собой набор реальных или виртуальных аппаратных линий, применяемых для передачи данных между компонентами компьютера или системы обработки. Системная шина 110 по существу представляет собой распределенный провод, который соединяет разные элементы компьютерной системы (например, процессор, дисковый накопитель, память, порты ввода/вывода и т.п.), что позволяет передавать данные между элементами.

[0046] К системной шине 110 подключен интерфейс 111 устройств ввода/вывода (I/O) для соединения различных устройств ввода и вывода (например, клавиатуры, манипулятора мышь, интерфейса сенсорного экрана, дисплеев, принтеров, динамиков, устройств ввода и вывода звука, гнезд микрофона и т.п.) с компьютером 150, 160. Сетевой интерфейс 113 позволяет компьютеру подключаться к различным другим устройствам, соединенным с сетью (например, сетью, представленной ссылкой 170 на фиг. 1A). Память 114 предоставляет энергонезависимое хранилище для компьютерных программных команд 115 и данных 116, используемых для осуществления программных реализаций компонентов аттестации сохранности устройств и аутентификации согласно некоторым вариантам осуществления настоящего изобретения. Такие программные компоненты 115, 116 аттестации сохранности устройств и аутентификации системы 100 аутентификации пользователей (например, кодировщик 210, апплет 208 доверенной среды выполнения (TEE), сайт 206 аутентификации, представленные на фиг. 2A), описанные в данном документе, могут быть выполнены с использованием любого языка программирования, включая любой объектно-ориентированный язык программирования высокого уровня, например, Python.

[0047] В одной иллюстративной мобильной реализации может быть предусмотрено осуществление настоящего изобретения в форме мобильного агента. Клиент-серверная среда может быть использована для обеспечения услуг мобильной безопасности с использованием сервера 190. Он может использовать, например, протокол XMPP для привязки механизма/агента 115 аутентификации устройств на устройстве 150 к серверу 160. Сервер 160 может затем по запросу отдавать команды на мобильный телефон. Инфраструктура мобильного интерфейса пользователя для доступа к определенным компонентам системы 100 может быть основана на XHP, Javelin и WURFL. В другой иллюстративной мобильной реализации для операционных систем OS X и iOS и их соответствующих API, Cocoa и Cocoa Touch, для реализации компонентов 115 на стороне клиента может быть использован Objective-C или любой другой язык программирования высокого уровня, который добавляет к языку программирования C передачу сообщений в стиле Smalltalk.

[0048] Система также может содержать экземпляры серверных процессов на серверных компьютерах 160, которые могут содержать механизм 240 (фиг. 2) аутентификации (или аттестации), который предоставляет возможность регистрации пользователя, выбора субъектов аутентификации/аттестации для подтверждения того, что запросчик является зарегистрированным пользователем, осуществления связи с субъектами аутентификации относительно подтверждения подлинности запросчика и выполнения алгоритмов, таких как статистические алгоритмы для вычисления степеней уверенности, чтобы разрешать или запрещать запросчику осуществлять доступ к ресурсам, защищенным системой.

[0049] Дисковый накопитель 117 предоставляет энергонезависимый накопитель для компьютерных программных команд 115 (эквивалентно «программа ОС») и данных 116, используемых для реализации вариантов осуществления системы 100. Система может содержать дисковый накопитель, доступный для серверного компьютера 160. Серверный компьютер может поддерживать безопасный доступ к записям, связанным с аутентификацией пользователей, зарегистрированных в системе 100. Центральный процессор 112 также соединен с системной шиной 110 и обеспечивает выполнение компьютерных команд.

[0050] В одном иллюстративном варианте осуществления процессорные подпрограммы 115 и данные 116 представляют собой компьютерные программные продукты. Например, если аспекты системы 100 аутентификации могут включать компоненты как на стороне сервера, так и на стороне клиента.

[0051] В одном иллюстративном варианте осуществления с субъектами аутентификации/аттестации можно связаться посредством приложений мгновенной передачи сообщений, систем для видеоконференций, VOIP-систем, систем электронной почты и т.п., которые все могут быть реализованы, по меньшей мере частично, в программном обеспечении 115, 116. В другом иллюстративном варианте осуществления механизм/агент аутентификации может быть реализован как программный интерфейс приложения (API), исполняемый программный компонент или интегрированный компонент OS, выполненный с возможностью аутентификации пользователей на модуле доверенной платформы (TPM), выполняющемся на вычислительном устройстве 150.

[0052] Программные реализации 115, 116 могут быть реализованы как машиночитаемый носитель, выполненный с возможностью хранения на устройстве 117 для хранения, который предоставляет по меньшей мере часть программных команд для системы 100 аутентификации пользователей. Исполнение экземпляров соответствующих программных компонентов системы 100 аутентификации пользователей, например, экземпляров механизма аутентификации, может быть реализовано в виде компьютерных программных продуктов 115, и они могут быть установлены любой подходящей процедурой установки программного обеспечения, как хорошо известно в данной области техники. В другом варианте осуществления по меньшей мере часть программных команд 115 системы может быть загружена по кабельному, коммуникационному и/или беспроводному соединению посредством, например, SSL сессии браузера или через приложение (выполняемое или с мобильного устройства, или с другого вычислительного устройства). В других вариантах осуществления программные компоненты 115 системы 100 могут быть реализованы как распространяемый сигналом компьютерный программный продукт, осуществленный в распространяемом сигнале в среде распространения (например, в радио волне, инфракрасной волне, лазерной волне, звуковой волне или электрической волне, распространяемой по глобальной сети, такой как Интернет, или другим сетям). Такие несущие среда или сигнал предоставляют по меньшей мере часть программных команд для настоящей системы 100 аутентификации устройств пользователя, представленной на фиг. 2A.

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

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

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

[0056] Один иллюстративный предпочтительный вариант осуществления содержит код устройства, выполняемый в доверенной среде выполнения (TEE). TEE предпочтительно представляет собой аппаратную среду, которая запускает малые апплеты за пределами основной OS. Это защищает закрытые код и данные от вредоносного программного обеспечения или отслеживания посредством специально созданного аппаратного обеспечения, управляемого взаимосвязанной системой подтверждений, начиная с производителя устройства.

[0057] Аттестация сохранности устройства/аутентификация - некоторые иллюстративные варианты осуществления

[0058] Фиг. 2A представляет собой структурную схему, демонстрирующую один пример системы аутентификации устройств согласно настоящему изобретению с компонентами 200. С помощью этих системных компонентов 200 веб-разработчики и разработчики приложений могут применять усиленное шифрование и ключи идентификации в конечных устройствах 205 пользователя посредством программного интерфейса приложений (API). Кроме того, могут быть предоставлены дополнительные услуги, построенные на этих системных компонентах 200 для управления устройством, резервирования, аттестации и т.п. Для поддержки этой системы производится управление регистрацией ключей идентификации и набором услуг управления устройствами для аттестации, резервирования и группировки устройств.

[0059] В предпочтительном иллюстративном варианте осуществления целью системы будет не сохранение особо важных данных, как в традиционных подходах, а скорее предоставление платформы для бесперебойных и при этом очень надежных соединений между поставщиками 204 услуг и устройствами 205 пользователя. На одном конце системы находится кодировщик 210, который подготавливает команду для устройства 205 пользователя, а на другом конце - ривет устройства, который представляет собой апплет 208 доверенной среды выполнения (TEE), который может действовать по этой команде. Протокол согласно одному варианту осуществления настоящего изобретения определяет формирование этих команд и ответов.

[0060] Ривет устройства или апплет 208 TEE предпочтительно реализует новаторскую связь между физическими и цифровыми работами. Ривет устройства или апплет 208 TEE закрывает свойства идентификации, транзакции и аттестации в аппаратном обеспечении устройства 205.

[0061] Система 200 согласно одному варианту осуществления настоящего изобретения, показанному на фиг. 2B, может использовать защищенный сокет для поддержания устойчивого соединения со всеми устройствами. Этот канал используется для сопряжения и других административных функций. Код 209 библиотеки может быть предоставлен поставщикам услуг для упрощения формирования и подписания команды. Эта библиотека 209, например, может быть реализована на языке программирования, таком как объектно-ориентированный язык программирования высокого уровня с динамической семантикой, например, как Python.

[0062] В одном иллюстративном предпочтительном варианте осуществления TEE может быть реализована в форме аппаратной отдельной среды выполнения с микросхемой безопасности для мобильного телефона, которая работает вместе с операционной системой с широкими функциональными возможностями (Rich) и предоставляет услуги безопасности для этой среды с широкими функциональными возможностями. TEE предлагает пространство выполнения, которое обеспечивает более высокий уровень безопасности, чем Rich OS. В другом иллюстративном варианте осуществления TEE может быть реализована в форме виртуальной машины. Хотя и не настолько защищенная, как элемент безопасности (SE) (также известный как SIM), безопасность, обеспечиваемая TEE, является достаточной для некоторых/многих приложений. Таким образом, TEE может предоставить баланс, обеспечивающий большую безопасность, чем среда Rich OS, со значительно более низкими затратами, чем SE.

[0063] Менеджер 212 кругов может быть реализован как услуга, предоставляемая конечным пользователям для управления собраниями (или кругами) устройств 205 пользователя. Устройства 205 могут быть сгруппированы в один идентификатор и использованы для резервирования и подтверждения друг друга. Круги могут быть связаны с другими кругами для создания сети устройств. В некоторых предпочтительных вариантах осуществления круги представляют собой собрание открытых ключей отдельных устройств (в противоположность новому ключу). Если в среде немного совместных устройств, предпочтительно список устройств предпочтительно может быть коротким по причине вероятности повышенного расходования вычислительных и полосных ресурсов и внесения временных затрат при шифровании сообщения со всеми открытыми ключами, имеющимися в списке устройства.

[0064] В непредпочтительном иллюстративном варианте осуществления круг может быть реализован как совместно используемый открытый ключ наряду с уникальным закрытым ключом устройства 205. Однако следует отметить, что совместное использование «закрытого ключа» не является типичной практикой, а также нежелательно и наличие совместно используемого симметричного ключа с длительным сроком существования.

[0065] Один аспект системы согласно одному варианту осуществления настоящего изобретения регистрирует устройство и снабжает его ключами поставщика услуг. Новаторские API предоставляют возможность безопасного выполнения ряда закрытых транзакций на стороне устройства, включая: получение надежного и анонимного id устройства - по запросу один вариант осуществления настоящего изобретения генерирует ключ подписи для устройства. Открытый ключ хешируют в строку, которая может быть использована для идентификации устройства и осуществления связи с ним. Закрытый ключ остается закрытым в аппаратном обеспечении и может быть применен только от имени услуги, которая запросила ID; выполнение устройством подписания чего-либо - закрытый ключ идентификатора устройства может быть использован для подписания вещей, доказывая участие этого конкретного устройства. Процедура подписания выполняется в защищенном аппаратном обеспечении, таким образом ключ никогда не раскрывается в обычной среде обработки устройства; выполнение устройством шифрования чего-либо - ключ шифрования может быть сгенерирован по запросу и применен к любому двоичному объекту данных. Шифрование и расшифровка запускаются локально и происходят в пределах безопасной среды выполнения, чтобы защитить ключ; создание счета Bitcoin - на устройство может быть подан запрос на создание нового счета Bitcoin с использованием генератора случайных чисел (RNG), встроенного в TEE; подписание транзакции Bitcoin - устройство может применить свой закрытый ключ счета Bitcoin для подписания транзакции и затем возвратить его поставщику услуг; защита подтверждения - более новые среды TEE поддерживают доверенные отображение и ввод в дополнение к доверенному выполнению. Доверенное отображение предоставляет возможность выдачи конечному пользователю простого сообщения с подтверждением, такого как «подтвердите сумму транзакции»; объединение устройств для совместного использования и резервирования идентификаторов - большинство пользователей имеют несколько устройств. Определенные варианты осуществления настоящего изобретения позволяют связывать несколько устройств в круг, таким образом они могут взаимозаменяемо представлять себя поставщику услуг от имени пользователя.

[0066] Поставщик услуг вызывает агента/процесс третьей стороны для создания аппаратных ключей в устройстве. Доступны разные типы ключей, в зависимости от цели, например, для криптовалют или шифрования данных. Аппаратные ключи управляются простыми правилами использования, установленными при создании. Например, ключ может требовать, чтобы запросы на использование были подписаны поставщиком услуг, создавшим ключ, или чтобы пользователь подтвердил доступ посредством доверенного интерфейса пользователя (TUI).

[0067] Ривет 208 устройства будет отвечать только на команды от поставщика 204 услуг, который был «сопряжен» с устройством 205. Веб-сайт 206 аутентификации выполняет процедуру сопряжения, когда имеет возможность подтвердить сохранность и идентификатор как устройства, так и поставщика услуг. При сопряжении устройство 205 получает открытый ключ поставщика 204 услуг, тогда как поставщик услуг получает уникальным образом сгенерированные идентификатор и открытый ключ для устройства 205.

[0068] Хотя агент/процесс третьей стороны поддерживает локальные вызовы, в идеале все команды подписываются поставщиком 204 услуг. Это защищает ключ устройства от применения несанкционированным приложением. Кодировщик 210 предусмотрен для помощи в подготовке и подписывании команд устройства на сервере приложений.

[0069] Имеется класс приложений, которые получают значительную выгоду от надежного подтверждения их происхождения и непрозрачного освобождения от выполнения других приложений. Он известен как доверенная среда выполнения (TEE). В отличие от приложения, работающего на основной OS и в стеке памяти, приложение, работающее в TEE, обладает доступом к криптографическим примитивам, которые могут быть выполнены без отслеживания со стороны OS. На определенных платформах приложение также имеет прямой доступ к пользовательскому вводу и отображению, чтобы гарантировать закрытое взаимодействие с оператором устройства. Хотя технологию развивают уже более десяти лет, устройства с поддержкой TEE стали доступны лишь недавно. Например, Intel начала поставку коммерческих решений в 2011 г., а Trustonic, совместное предприятие с участием ARM, было основано в 2013 г..

[0070] Разворачивание апплета в TEE похоже на поставку специализированного аппаратного устройства. Выполнение и данные криптографически изолированы от любой другой функции вмещающего устройства. Хотя большинство приложений технологии доверенного выполнения были связаны с корпоративной безопасностью или DRM, один вариант осуществления настоящего изобретения вместо этого предусматривает апплет, который нацелен на потребности обычных веб-сервисов. Криптовалюты, такие как Bitcoin, показали необходимость в безопасности потребительских ключей.

[0071] Один вариант осуществления настоящего изобретения предусматривает собственный API, который переводит вызовы в защищенную среду. Хотя разные среды TEE следуют очень разным типам архитектуры, API согласно одному варианту осуществления настоящего изобретения выполнен с возможностью предоставления единообразного интерфейса для приложения.

Как и в случае всех апплетов TEE, апплеты TEE согласно вариантам осуществления настоящего изобретения не могут быть установлены и инициализированы без диспетчера доверенных приложений (TAM). TAM играет роль, подобную уполномоченному субъекту сертификации (CA). TAM обеспечивает безопасность взаимосвязи с производителем устройства, а также подписывает все апплеты, которые могут быть загружены на устройство. Таким образом, TAM выдает подтверждение о происхождении и сохранности как апплета, так и TEE.

[0072] Аттестация сохранности устройства

[0073] Варианты осуществления настоящего изобретения предусматривают аттестацию сохранности устройства посредством автоматизации подтверждения сохранности устройства в сравнении с известным состоянием как подписанта в транзакции цепочки блоков. Система, реализованная одним вариантом осуществления настоящего изобретения, состоит из нескольких компонентов, представленных на фиг. 2C. Адаптер 220 устройств представляет собой программную службу, работающую на конечном устройстве, которая предоставляет интерфейс для приложения поставщика 204 услуг и интегрируется с TEE 208 устройства. Доверенная среда выполнения (TEE, иногда TrEE) представляет собой аппаратную отдельную среду выполнения с микросхемой безопасности для мобильного телефона, которая работает вместе с Rich OS и предоставляет услуги безопасности для этой среды с широкими функциональными возможностями. TEE предоставляет пространство выполнения, которое обеспечивает более высокий уровень безопасности, чем Rich ОS; хотя и не настолько защищенная, как элемент безопасности (SE) (известный также как SIM), безопасность, предоставляемая TEE, является достаточной для некоторых/многих приложений. Таким образом, TEE предоставляет баланс, обеспечивающий большую безопасность, чем среда Rich ОS, со значительно более низкими затратами, чем SE. Другой компонент, TEE 208 устройства, представляет собой прикладную программу, которая выполняется в аппаратно защищенной TEE. TEE 208 устройства специально предназначена для выполнения криптографических функций без возможности нарушения безопасности со стороны вредоносного программного обеспечения или даже оператора устройства. Другой компонент, регистратор 221 устройств, представляет собой службу, которая регистрирует устройство в цепочке 222 блоков. Цепочка 222 блоков применяется как для хранения параметров регистрации и атрибутов устройства, так и для выполнения транзакций. Цепочки блоков могут быть разными. Другим вспомогательным компонентом является поставщик 204 услуг, который представляет собой приложение, предпринимающее попытку проведения транзакции с устройством. Оригинальный производитель 223 оборудования (OEM) является субъектом, создавшим устройство и/или диспетчер доверенных приложений (TAM), авторизованный криптографическим способом выдавать подтверждение о происхождении устройства.

[0074] Согласно одному варианту осуществления настоящего изобретения, когда адаптер 221 устройств, представленный на фиг. 2C, программно выполняется в первый раз, он подает запрос на TEE 208 устройства сгенерировать пару открытого/закрытого ключей. Открытый ключ подписывается ключом подтверждения, установленным во время производства устройства. Этот подписанный открытый ключ отправляют на регистратор 221 устройств и подтверждают его подлинность посредством OEM 223. Регистрация может включать подтверждение со стороны оператора устройства. Регистрация может включать подтверждение в точке продажи в присутствии служащего. Регистратор может запрашивать у устройства запись значений измерения устройства, содержащую одно или более из следующего: составное значение регистров конфигурации платформы (PCR), сгенерированное посредством процесса загрузки, версию BIOS, версию OS, определенное посредством GPS местоположение. Эти данные подписывают закрытым ключом устройства. Их дополнительно подписывает регистратор. Получающийся в результате набор данных становится эталонным образцом или опорным значением для будущих проверок сохранности. Подтверждение со стороны оператора устройства может потребоваться при составлении эталонного образца или опорного значения. Этот набор данных помещают в открытую криптографическую книгу учета. Открытая запись устанавливает криптографическое свидетельство времени регистрации вместе с подтверждением регистратора. Регистрация может дополнительно включать атрибутивные данные, такие как местоположение или название компании, или сборка/модель устройства. Регистрация может ссылаться на подписанный документ, который указывает условия политики регистратора на момент регистрации. Регистратор 221 устройств или другой доверенный сервер сохранности создает ключ счета цепочки блоков (пару открытого/закрытого ключей), на который можно ссылаться как на подписанта в транзакции с несколькими подписями в цепочке блоков. Подписанное значение, представленное в транзакции цепочки блоков, не может быть использовано или передано, если только не подписано совместно с регистратором.

[0075] Для подписания транзакции сервер сохранности ожидает получения последнего значения измерения с устройства. Это значение измерения может быть запрошено прямо у адаптера устройств или извлечено сервером посредством устойчивого сокет-соединения с устройством. Текущее значение измерения сравнивают с эталонным значением измерения или опорным значением в цепочке блоков. Если значения измерения соответствуют, транзакцию подписывают. Если значения измерения соответствуют, но последнее значение измерения старше, чем заданное временное окно, то запрос отклоняют. Если значения измерения не соответствуют, запрос отклоняют. В случае отклонения транзакция может быть подготовлена с помощью другого ручного подписанта, которому может быть отправлен запрос на преодоление отклонения. Если значения измерения не соответствуют, устройство может быть подвергнуто обновлению регистрации, во время которого собирают новые значения измерения. Каждый раз, когда значения измерения соответствуют, запись о регистрации устройства может быть обновлена счетчиком успеха. Сервер сохранности может быть снабжен правилами политики, которые принимают не соответствующее значение измерения, если проблема не считается серьезной в свете других соответствующих значений измерений или атрибутов.

[0076] Система согласно одному варианту осуществления настоящего изобретения может быть реализована с собранием доверенных устройств, вместо того, чтобы сервер сохранности выполнял работу по сопоставлению значений измерения и подписанию транзакции. Система может сопоставлять значения измерения сохранности прямо во время обработки транзакции с использованием признаков, встроенных в умную систему цепочки блоков, такую как сейчас разрабатывается на платформе Ethereum.

[0077] Аттестация сохранности устройства - веб-сайт аутентификации

[0078] В одном иллюстративном варианте осуществления веб-сайт 206 аутентификации может представлять собой JSON API, написанный на Python, использующий закрытый ключ агента/процесса третьей стороны для регистрации ключей идентификации устройств 205 и поставщиков 204 услуг. Во время регистрации открытый ключ устройства 205 пользователя или поставщика 204 услуг записывается апплетом 208 TEE. Регистрация позволяет апплету 208 TEE сопрягать устройство 205 с поставщиком 204 услуг. Результатом сопряжения является то, что устройство 205 пользователя имеет открытый ключ услуг, подтвержденный агентом/процессом третьей стороны, и, следовательно, может отвечать на команды поставщика 204 услуг.

[0079] Протокол согласно одному варианту осуществления настоящего изобретения определяет структуру команды и подписание/шифрование, которые должны быть применены, чтобы устройство 205 приняло команду. Сама команда может, к примеру, быть подготовлена как структура C, содержащая код команды, данные о версии и полезные данные. Вся структура предпочтительно подписывается ключом поставщика услуг и доставляется на апплет 208 TEE устройства посредством вызова локальной команды устройства.

[0080] Предпочтительно каждое устройство 205 пользователя должно предоставлять уникальные удостоверяющие данные идентификации. Устройства могут объединяться в круг, так чтобы действовать как один субъект. В одном варианте осуществления устройство 205 может поддерживать групповые ID, которые хранятся локально списком, но открыто переводятся в кросс-платформенную аутентификацию. Адаптер 216 TEE может быть выполнен в форме интерфейса между риветом устройства/апплетом 208 TEE, встроенным в TEE, и внешним миром партнерских приложений и онлайн-служб. При реализации он может выражаться в одной или более различных формах, которые по меньшей мере частично будут определяться основными функциональными возможностями устройств, поддержкой аппаратного обеспечения и архитектурой OS.

[0081] Аттестация сохранности устройства - адаптер системы аутентификации

Адаптер 214 системы аутентификации состоит из внешних и внутренних интерфейсов, как представлено на фиг. 2D. Внутренний интерфейс, адаптер 216 TEE, отвечает за осуществление внутренней связи с риветом 208 устройства. Хост-адаптер 217 предусмотрен для предоставления услуг приложениям третьих сторон. Хост-адаптер 217 представляет интерфейс адаптера 214 системы аутентификации посредством разных локальных контекстов, таких как браузеры или системные службы. Предполагаются множественные реализации для разнообразных контекстов, хотя изначально это может быть служба Android и com-процесс Windows. Сокет-адаптер 215 подключает веб-сайт 206 аутентификации клиентской среды. Компонент адаптера 216 TEE представляет собой внутренний связующий элемент, который передает команды на ривет 208 устройства. В реализации на Android адаптер 214 системы аутентификации может быть представлен в виде служебного приложения Android NDK и может быть настроен запускаться при загрузке. Адаптер 214 системы аутентификации подготавливает буферы сообщений, которые направляются на ривет 208 устройства, и затем синхронно ожидает уведомления об ответном событии. Хост-адаптер 217 в первую очередь предназначен для изоляции адаптера 216 TEE от хост-среды. Хост-адаптер 217 работает в потенциально враждебной среде. Следовательно, как правило, будет ограниченная уверенность в том, что безопасность клиента не была нарушена. Следовательно, роль хост-адаптера в первую очередь заключается в том, чтобы способствовать легкому доступу к ривету 208 устройства. Команды от поставщика 204 услуг, предназначенные для ривета 208 устройства, будут подписаны поставщиком 204 услуг и затем пропущены на адаптер 216 TEE и ривет 208 устройства.

[0082] Первый поставщик услуг, зарегистрированный на устройстве

[0083] Согласно одному иллюстративному варианту осуществления веб-сайт 206 аутентификации является первым поставщиком услуг, зарегистрированным на устройстве 205. Веб-сайт 206 аутентификации имеет особую функциональную возможность выполнять сопряжение дополнительных поставщиков услуг с этим устройством 205. Связь с веб-сайтом 206 аутентификации может быть реализована посредством веб- API и должна быть аутентифицирована. В одном примере это реализовано с помощью ключа API. В одном предпочтительном иллюстративном варианте осуществления это реализовано с использованием обмена ключами по SSL. В некоторых вариантах осуществления все запросы будут подписаны.

[0084] Взаимосвязь с устройствами может зависеть от наличия возможности подписания команд закрытым ключом. Такой закрытый ключ является крайне важным и защищенным. Предпочтительно закрытый ключ заключен в HSM (аппаратном модуле защиты).

[0085] В некоторых вариантах осуществления применяют несколько ключей, таким образом, в случае нарушения безопасности одного из них система целиком не будет потеряна. Это, например, должно затруднить для взломщика получения знаний о том, какие устройства связаны с ключом, безопасность которого была нарушена. Кроме того, система 200 предпочтительно находится в почти постоянном контакте со всеми устройствами 205 посредством сокет-адаптера 215, представленного на фиг. 2C, что может способствовать частому обращению ключей.

Веб-сайт 206 аутентификации может содержать несколько подкомпонентов. ID устройства представляет собой уникальный идентификатор, в UUID, назначенный для устройства веб-сайтом 206 аутентификации или другим агентом регистрации. Кратковременный указатель, указатель устройства, может быть предоставлен для устройства 150 и может быть запрошен любым локальным приложением. Указатель устройства может идентифицировать текущую сессию сокета с веб-сайтом 206 аутентификации и, следовательно, может быть использован для установления канала связи устройства и поиска постоянного идентификатора, ID устройства. Корень регистрации устройства содержит уникальный анонимный идентификатор, дату регистрации, открытый ключ, связанный парой с закрытым ключом, содержащимся в аппаратном обеспечении устройства, и подтверждающую подпись от агента регистрации. Эту информацию записывают в записи о регистрации устройства. Апплет 208 TEE осуществляет связывание между физическими и цифровыми работами. Ривет 209 устройства закрывает признаки идентификации, транзакции и аттестации в аппаратном обеспечении.

[0086] Протокол для обработки команд

[0087] Контрагентом ривета 209 устройства является кодировщик 210. Кодировщик 210 подготавливает команду, которую необходимо выполнить определенным устройством, которая подписывается и/или шифруется поставщиком 204 услуг. Открытые ключи поставщика услуг предварительно загружены на устройство во время процесса сопряжения, выполненного веб-сайтом 206 аутентификации. Это позволяет ривету 209 устройства подтверждать происхождение запроса и при необходимости расшифровывать содержимое команды.

Последовательность упаковки и доставки команды представлена на фиг. 3A. Поставщик 204 услуг генерирует запись команды с помощью библиотек кодировщика 210. Команда включает тип, целевое устройство и полезные данные. Команда может быть закодирована ключом устройства и должна быть подписана ключом поставщика услуг. Ключ устройства извлекается из веб-сайта 206 аутентификации или непосредственно из цепочки блоков посредством поиска записи о регистрации устройства.

[0088] Протокол для регистрации устройства

[0089] Регистрация устройства или создание сертификата выпуска для устройства в цепочке блоков является обязательным для иллюстративных вариантов осуществления настоящего изобретения. Процесс регистрации, представленный на фиг. 3B, должен быть простым в применении или даже очевидным для пользователя. В идеале полностью заслуживающий доверия ID устройства включает персонализацию взаимоотношения между устройством и пользователем посредством PIN или другого испытания памяти; а также легальное связывание между пользователем и устройством, например, посредством регистрации устройства в присутствии продавца. Он производит поиск ключей подтверждения OEM, который изготовил устройство, чтобы убедиться в происхождении. Он также может включать специальную подготовку мощности и анонимности регистрации устройства. Начать можно просто с понятного создания ID. По причине этой переменчивости в контексте регистрации агенту регистрации следует записывать контекст регистрации, чтобы гарантировать, что соответствие критериями безопасности выполняется там, где следует. Например, проверка ключа подтверждения OEM дает значительно больше гарантий того, что ривет устройства работает в надлежащей TEE.

[0090] В одном иллюстративном варианте осуществления, представленном на фиг. 2C, когда программное обеспечение адаптера 220 устройства запускается впервые, оно запрашивает у TEE 208 устройства генерирование пары открытого/закрытого ключей. Открытый ключ подписывается ключом подтверждения, установленным во время производства устройства. Этот подписанный открытый ключ отправляют на регистратор 221 устройств и подтверждают его подлинность посредством OEM 223. Регистрация может включать подтверждение от оператора устройства, или регистрация может включать подтверждение в точке продажи в присутствии служащего. Регистратор 221 запрашивает у устройства запись значений измерения устройства, которая содержит одно или более из следующего: составное значение регистров конфигурации платформы (PCR), созданное процессом загрузки, версию BIOS, версию OS, определенное посредством GPS местоположение, идентификатор BIOS, идентификатор сетевого интерфейса, атрибуты устройства, такие как количество файлов, размер файлов, директорий, индексов и структур деревьев данных/поиска, определяющий процессор номер устройства или другую подобную информацию. Эти данные подписывают закрытым ключом устройства, и они могут быть дополнительно подписаны регистратором 221. Получающийся в результате набор данных становится эталонным образцом для будущих проверок сохранности. Подтверждение со стороны оператора устройства может потребоваться при составлении эталонного образца. Этот набор данных помещают в открытую криптографическую книгу учета, такую как Namecoin. Открытая запись устанавливает криптографическое свидетельство времени регистрации вместе с подтверждением регистратора. Регистрация может дополнительно включать другие атрибутивные данные, такие как местоположение или наименование компании, или сборка/модель устройства. Регистрация может ссылаться на подписанный документ, который указывает условия политики регистратора на момент регистрации. Регистратор 221 устройств или другой доверенный сервер сохранности создает ключ счета цепочки блоков (пару открытого/закрытого ключей), на который можно ссылаться как на подписанта в транзакции с несколькими подписями в цепочке блоков. Подписанное значение, представленное в транзакции цепочки блоков, не может быть использовано/передано, если только не подписано совместно с регистратором 221. Для подписания транзакции сервер сохранности ожидает получения последнего значения измерения с устройства. Это значение измерения может быть запрошено прямо у адаптера устройств или извлечено сервером посредством устойчивого сокет-соединения с устройством. Текущее значение измерения сравнивают с эталонным значением измерения в цепочке блоков. Если значения измерения соответствуют, транзакцию подписывают, если измерения соответствуют, но последнее значение измерения старше, чем заданное временное окно, то запрос отклоняют. Если значения измерения не соответствуют, запрос отклоняют. В случае отклонения транзакция может быть подготовлена с помощью другого ручного подписанта, которому может быть отправлен запрос на преодоление отклонения. Если значения измерения не соответствуют, устройство может быть подвергнуто обновлению регистрации, во время которого собирают новые значения измерения. Каждый раз, когда значения измерения соответствуют, запись о регистрации устройства может быть обновлена счетчиком успеха. Сервер сохранности может быть снабжен правилами политики, которые принимают не соответствующее значение измерения, если проблема не считается серьезной в свете других соответствующих значений измерений или атрибутов. Эта система может быть реализована с собранием доверенных устройств, вместо того, чтобы сервер сохранности выполнял работу по сопоставлению значений измерения и подписанию транзакции. Эта система может сопоставлять значения измерения сохранности прямо во время обработки транзакции с использованием признаков, встроенных в умную систему цепочки блоков, такую как сейчас разрабатывается на платформе Ethereum.

[0091] Сертификат выпуска для устройства в цепочке блоков

[0092] Один вариант осуществления может представлять собой способ создания сертификата выпуска для устройства пользователя в коммуникационной сети цепочки блоков, включающий: установление идентификатора устройства для устройства пользователя посредством генерирования пары открытого/закрытого ключей, которая привязана к устройству пользователя; подписание открытого ключа устройства ключом подтверждения, установленным во время изготовления или создания устройства, изготовления или создания среды выполнения устройства и/или изготовления или создания приложения на устройстве; и регистрацию устройства доверенной третьей стороной, включающую: запрос и получение сгенерированного открытого ключа с устройства; запрос и получение записи значений измерения устройства, содержащей атрибуты, связанные с регистрами конфигурации платформы (PCR) устройства, BIOS, OS и/или GPS; подтверждение записи значений измерения устройства третьей стороной и устройством и регистрацию устройства в цепочке блоков, включающую размещение подтвержденной записи измерения устройства в открытой криптографической книге учета и создание пары ключей счета цепочки блоков, на которую можно ссылаться как на подписанта в транзакции с несколькими подписями в цепочке блоков. В некоторых вариантах осуществления способ может включать проведение регистрации устройства третьей стороной по запросу первого поставщика услуг, который предпринимает попытку сопряжения с устройством. В некоторых вариантах осуществления регистрация устройства может быть предоставлена как услуга. Подтверждение записи значений измерения устройства устройством может включать подписание записи закрытым ключом устройства. Подтверждение записи значений измерения устройства третьей стороной может быть предоставлено как услуга. Регистрация может дополнительно включать подписание документа, который указывает условия политики поставщика регистрации на момент регистрации. Открытая криптографическая книга учета может представлять собой Namecoin. Подтвержденная запись значений измерения устройства может устанавливать опорное значение для транзакций между поставщиком услуг и устройством. Дополнительно подтверждение от оператора устройства требуется для получения записи значений измерения устройства, состоящей из атрибутов устройства, с устройства. Атрибуты устройства могут дополнительно включать местоположение, название компании и/или сборку/модель устройства. Кроме того, транзакция между поставщиком услуг и устройством может требовать от устройства генерирования и предоставления записи значений измерения устройства, которую сравнивают с установленным опорным значением для устройства. В других вариантах осуществления транзакцию разрешают, если результаты сравнения соответствуют, или транзакцию отклоняют, если результаты сравнения не соответствуют, или транзакцию отклоняют, если результаты сравнения соответствуют, и запись, предоставленная устройством, старше, чем заданное временное окно, или от устройства требуется повторное создание его сертификата выпуска, если результаты сравнения не соответствуют. Дополнительно регистрация устройства в цепочке блоков может также включать создание записи о регистрации устройства, которую обновляют счетчиком успеха, если результаты сравнения соответствуют. Сравнение может быть реализовано посредством собрания доверенных устройств. Субъект, выполняющий сравнение, может быть независим от субъекта, выполняющего регистрацию.

[0093] Другой вариант осуществления может представлять собой систему, содержащую коммуникационную сеть цепочки блоков; устройство пользователя в сети цепочки блоков; доверенную третью сторону и систему для создания сертификата выпуска для устройства пользователя, причем указанная система выполнена с возможностью установления идентификатора устройства для устройства пользователя посредством генерирования пары открытого/закрытого ключей, которая привязана к устройству пользователя; подписания открытого ключа устройства с использованием ключа подтверждения, установленного во время изготовления или создания устройства, изготовления или создания среды выполнения устройства и/или изготовления или создания приложения на устройстве; и регистрации устройства доверенной третьей стороной посредством: запроса и получения сгенерированного открытого ключа с устройства; запроса и получения записи значений измерения устройства, содержащей атрибуты, связанные с регистрами конфигурации платформы (PCR) устройства, BIOS, OS и/или GPS; подтверждения записи значений измерения устройства третьей стороной и устройством; и регистрации устройства в цепочке блоков посредством размещения подтвержденной записи измерения устройства в открытую криптографическую книгу учета; и создания пары ключей счета цепочки блоков, на которую можно ссылаться как на подписанта в транзакции с несколькими подписями в цепочке блоков.

[0094] Применение транзакций в цепочке блоков для аккумулирования прав владения

[0095] Кошелек Bitcoin функционирует подобно банковскому счету и может быть использован для получения и хранения монет Bitcoin, а также передачи их другим в виде электронной транзакции в цепочке блоков Bitcoin. Адрес Bitcoin представляет собой уникальный идентификатор, который позволяет пользователю получать монеты Bitcoin. Монеты Bitcoin передают путем отправки их на адрес Bitcoin. Транзакции в цепочке блоков Bitcoin обычно являются бесплатными. Однако с транзакций, которые отправляют и получают монеты Bitcoin с использованием большого количества адресов, обычно снимают плату за транзакцию. Кошелек хранит закрытые ключи таким образом, что пользователь может осуществлять доступ к адресам Bitcoin.

[0096] Могут быть предусмотрены системы и способы, посредством которых транзакция на цепочке блоков аккумулирует или приобретает право владения.

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

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

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

[00100] Может быть предусмотрена система для аккумулирования ценности, связанной с транзакциями в коммуникационной сети цепочки блоков, связанной со счетом Bitcoin, при этом система содержит коммуникационную сеть цепочки блоков; электронную транзакцию в сети цепочки блоков; счет Bitcoin; запись о транзакции, связанную со счетом Bitcoin; процесс урегулирования транзакции, реализованный в качестве части выполнения электронной транзакции в сети цепочки блоков. Реализация может дополнительно содержать проверку записи о транзакции на существование предыдущей транзакции, связанной со счетом; и на основе существования предыдущей транзакции: получать аккумулированную ценность, связанную с предыдущей транзакцией; наращивать полученную аккумулированную ценность; связывать наращенную аккумулированную ценность с транзакцией в записи о транзакции и применять наращенную аккумулированную ценность к транзакции.

[00101] Реализация процесса урегулирования транзакции может дополнительно включать

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

[00102] Реализация процесса урегулирования транзакции может дополнительно включать

создание новой записи о транзакции, связанной со счетом, и сохранение указания о

полученном праве в новосозданной записи о транзакции.

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

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

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

[00106] В некоторых системах транзакция связана с одним товаром и включает два полученных права, и аккумулированные ценности, связанные с правами, криптографически объединяют с получением в результате одной аккумулированной ценности.

[00107] Гарантированные компьютерные команды для облачных служб и одноранговых служб

[00108] Текущее состояние информационных технологий основано на модели аутентификации, в которой устройства подключаются к облачной службе, такой как Twitter, и затем полагают, что последующие данные являются правильными. Часто используют зашифрованную передачу, и модель подтверждения основана на подтверждении всего компьютера, который отправляет данные. Для хост-системы предусмотрены такие технологии как антивирус и подтверждение сохранности. Делается предположение, что сложная система в порядке и ей можно доверить доставляемые критически важные данные.

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

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

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

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

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

[00114] Некоторые системы могут задействовать локальные аттестационные данные, чтобы гарантировать, что изолированная среда выполнения может доказать, что она находится в известном состоянии во время транзакции.

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

[00116] Системы могут включать локальные или удаленные одобрения перед запуском транзакции (т.е. мультисигнал на стороне клиента). Системы могут принимать данные в реальном времени, которые подтверждаются локально и затем модифицируются так, чтобы команда представляла собой некоторое изменение для состояния в реальном времени, например, для увеличения скорости блока приема-передачи данных. В некоторых системах проверяющее устройство подтверждает, что транзакция поступила из известного источника и соответствует минимальному числу параметров. В других системах принимающее устройство дополнительно проверяет локальную или удаленную информацию.

[00117] Хотя настоящее изобретение было в частности представлено и описано со ссылками на его иллюстративные варианты осуществления, специалистам в данной области техники будет понятно, что различные изменения в форме и деталях могут быть осуществлены в нем без отхода от объема изобретения, охваченного прилагаемой формулой изобретения.

[00118]

1. Спецификация компонентов

• Спецификация компонентов

• Обзор системы

• Принципы

• Системные компоненты

• Системные функции

2. Обзор системы

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

Rivetz состоит из:

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

• Веб-службы, находящейся на хостинге Rivetz.net, которая предоставляет возможность регистрации и сопряжения устройств и служб.

• Протокола, согласно которому команды передаются на устройство от поставщика услуг.

Rivetz.net будет дополнительно предоставлять услуги, основанные на этой инфраструктуре, для управления устройствами, резервирования, аттестации и т.д.

Rivetz.net представляет собой JSON API, написанный на Python, использующий закрытый ключ Rivetz для регистрации ключей идентификации устройств и поставщиков услуг. Во время регистрации Rivetz записывает открытый ключ устройства или поставщика услуг. Регистрация позволяет Rivetz производить сопряжение устройства с поставщиком услуг. Результатом сопряжения является то, что устройство имеет открытый ключ услуги, подтвержденный Rivetz, и, следовательно, может отвечать на команды поставщика услуг.

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

Rivetz применяет защищенный сокет для поддержания постоянного соединения со всеми устройствами, оснащенными риветами. Этот канал используется для сопряжения и других административных функций.

Rivetz предоставляет поставщикам услуг код библиотеки для упрощения формирования и подписания команды. Эта библиотека изначально будет предоставлена на языке Python. Другие языки последуют.

3. Принципы

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

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

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

• Мы лишь отвечаем за аппаратное обеспечение - Rivetz лишь выражает доверие криптографическим примитивам, реализованным на основе аппаратного обеспечения. При отсутствии мы не будем пытаться «усилить» слабый корень, а будем предупреждать относительно уровня доверия конечной точки.

4. Системные компоненты

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

Замысел Rivetz состоит в том, чтобы не управлять особо важными данными, а предоставлять платформу для непрерывных, но очень надежных соединений между поставщиками услуг и устройствами. На одной стороне находится Кодировщик Rivetz, который подготавливает команду для устройства, а на другой стороне находится Ривет устройства, который представляет собой апплет TEE, который может действовать по этой команде. Протокол Rivetz определяет, как формируются эти команды и реакции

Название нового компонента:

Таблица 1

Компонент	определение
Ривет устройства	Апплет TEE Rivetz, который реализует наше связывание между физическими и цифровыми работами. Ривет устройства ограничивает признаки идентификации, транзакции и аттестации аппаратным обеспечением и формирует основу нашего технического предложения.
Менеджер кругов	Менеджер кругов представляет собой услугу, предоставляемую конечным пользователям для управления собраниями (или кругами) устройств. Устройства могут быть сгруппированы в один идентификатор и использованы для резервирования и подтверждения друг друга. Круги могут быть связаны с другими кругами для создания сети устройств.
Адаптер ривета	Адаптер ривета представляет собой интерфейс между Риветом устройства, встроенным в TEE, и внешним миром партнерских приложений и онлайн-служб. При реализации он проявляется в одной или нескольких разнообразных формах. Хотя мы стараемся предоставить на устройствах одинаковые основные функциональные возможности, аппаратная поддержка и архитектура OS будут определять то, что фактически возможно, и как эти признаки представляются.
Кодировщик Rivetz	Кодировщик Rivetz создает Запись команды и обрабатывает Запись ответа. Они представляют собой структуры данных сообщений, которые определены для Ривета устройства (доверенного приложения) и интерпретируются им.
Rivetz Net	RivetzNet представляет собой службу, управляемую Rivetz, для сопряжения устройств и поставщиков услуг в одобренную взаимосвязь.

5. Системные функции

Пожалуйста, обращайтесь к RivetzUseCases

6. Менеджер кругов

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

• Менеджер кругов

• Контекст компонентов

• Схема компонентов

• Декомпозиция компонентов

• Ответственность субъекта

• Спецификация интерфейса

7. Контекст компонентов

(упаковка, образы, инфраструктуры, предпосылки, применение)

8. Схема компонентов

9. ДЕКОМПОЗИЦИЯ КОМПОНЕНТОВ

Название нового компонента:

Определение

компонента

10. Ответственность субъекта

(коммерческие или технические субъекты, управляемые этим компонентом)

11. Спецификация интерфейса

12. Rivetz Net

RivetzNet представляет собой службу, управляемую Rivetz, для сопряжения устройств и поставщиков услуг в одобренную взаимосвязь.

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

• Rivetz Net

• Контекст компонентов

• Веб API

• Закрытый ключ

• Ответственность субъекта

• Спецификация интерфейса

• Зарегистрировать устройство

• Зарегистрировать поставщика услуг

• Получить ID устройства

• Выполнить сопряжение устройства

• Ссылка на варианты применения

13. Контекст компонентов

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

14. Веб API

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

15. Закрытый ключ

Взаимосвязь Rivetz с устройствами зависит от возможности подписания команд нашим закрытым. Разумеется, чрезвычайно важно, чтобы этот ключ был защищен. Нам следует попытаться заключить ключ в HSM.

16. Ответственность субъекта

(коммерческие или технические субъекты, управляемые этим компонентом)

Название нового субъекта:

Таблица 2

Субъект	определение
ID устройства	Уникальный идентификатор, в UUID, назначенный для устройства RivetzNet или другим Агентом регистрации.
Указатель устройства	Кратковременный указатель на устройство, который может быть запрошен любым локальным приложением. Указатель устройства может идентифицировать текущую сессию сокета с RivetzNet и, следовательно, может быть использован для установления канала связи устройства и поиска постоянного идентификатора, ID устройства.
Запись о регистрации устройства	Корень регистрации устройства содержит уникальный анонимный идентификатор, дату регистрации, открытый ключ, связанный парой с закрытым ключом, содержащимся в аппаратном обеспечении устройства, и подтверждающую подпись от Агента регистрации (на данный момент - Rivetz).
ID отправления	Уникальный идентификатор, используемый для сопоставления Записи команды, отправляемой с RivetzNet, с Записью ответа, возвращаемой Адаптером ривета
Учетная запись Rivetz Coin	RivetzNet использует инфраструктуру цепочки блоков (в настоящее время - Namecoin) для хранения, пометки и публикации своих регистраций. Это осуществляется путем покупки записи пары имя/значение в цепочке блоков и, следовательно, необходимо иметь исходящую учетную запись. Тот факт, что управляемая Rivetz учетная запись купила запись, интерпретируют как подтверждение.
Ключ идентификации Rivetz	Для представления подтверждения Rivetz Corp генерируют уникальную пару открытого/закрытого ключей. Эту пару ключей следует часто менять и защищать в аппаратном обеспечении. В идеале наш протокол был бы таким, что даже в случае кражи пары ключей безопасность системы чрезмерно не нарушается.
ID поставщика услуг (Service Provider ID)	Уникальный идентификатор, назначенный Поставщику услуг от RivetzNet.
Запись о регистрации поставщика услуг	Запись, созданная для каждого зарегистрированного поставщика услуг, который хочет отправлять команды на устройство, оснащенное риветом. Она содержит название поставщика услуг, дату регистрации, открытый ключ и подтверждающую подпись (от Rivetz).

17. Спецификация интерфейса

18. Зарегистрировать устройство

При получении уникального идентификатора и открытого ключа осуществляется покупка записи этой связки в цепочке блоков. Покупка осуществляется с помощью Учетной записи RivetzCoin, таким образом подтверждая регистрацию. В идеале подпись Rivetz применялась бы только в случае, если устройство может предоставить ключ подтверждения от OEM.

19. Зарегистрировать поставщика услуг

Создает ID поставщика услуг для данной организации. Регистрация также должна содержать URL, по которому SP размещает свою реализацию Кодировщика Rivetz, и открытый ключ идентификации для проверки сеансов связи.

20. Получить ID устройства

При получении Указателя устройства возвращает ID устройства, известный запрашивающему Поставщику услуг.

Таблица 3

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

Возвраты: ID устройства

21. Выполнить сопряжение устройства

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

Таблица 4

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

22. Ссылка на варианты применения

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

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

• Регистрация поставщика услуг на Rivetz - Любому, кто хочет использовать систему шифрования Rivetz, необходимо зарегистрироваться в качестве поставщика услуг. Начальная регистрация представляет собой просто заполнение формы на RivetzNet (http://rivetz...

WebHome > AcronymTable > HSM

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

1. ID устройства

Уникальный идентификатор, в UUID, назначенный устройству RivetzNet или другим Агентом регистрации.

2. Указатель устройства

Кратковременный указатель на устройство, который может быть запрошен любым локальным приложением. Указатель устройства может идентифицировать текущую сессию сокета с RivetzNet и, следовательно, может быть использован для установления канала связи устройства и поиска постоянного идентификатора, ID устройства.

Тип данных:

3. Ключ идентификации Rivetz

Для представления подтверждения Rivetz Corp генерируют уникальную пару открытого/закрытого ключей. Эту пару ключей следует часто менять и защищать в аппаратном обеспечении. В идеале наш протокол был бы таким, что даже в случае кражи пары ключей безопасность системы чрезмерно не нарушается.

4. Запись о регистрации устройства

Корень регистрации устройства содержит уникальный анонимный идентификатор, дату регистрации, открытый ключ, связанный парой с закрытым ключом, содержащимся в аппаратном обеспечении устройства, и подтверждающую подпись от Агента регистрации (на данный момент - Rivetz).

5. ID отправления

Уникальный идентификатор, используемый для сопоставления Записи команды, отправляемой с RivetzNet, с Записью ответа, возвращаемой Адаптером ривета.

6. Учетная запись Rivetz Coin

RivetzNet использует инфраструктуру цепочки блоков (в настоящее время - Namecoin) для хранения, пометки и публикации своих регистраций. Это осуществляется путем покупки записи пары имя/значение в цепочке блоков и, следовательно, необходимо иметь исходящую учетную запись. Тот факт, что управляемая Rivetz учетная запись купила запись, интерпретируют как подтверждение.

7. ID поставщика услуг

Уникальный идентификатор, назначенный Поставщику услуг от RivetzNet.

8. Запись о регистрации поставщика услуг

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

9. Кодировщик Rivetz

Кодировщик Rivetz создает Запись команды и обрабатывает Запись ответа. Они представляют собой структуры данных сообщений, которые определены для Ривета устройства (доверенного приложения) и интерпретируются им.

а) Контекст компонентов

Кодировщик Rivetz представляет собой программное обеспечение, написанное для размещения нашими партнерами.

Кодировщик Rivetz распространяется с открытым исходным кодом.

b. Ответственность субъекта

Название нового субъекта:

c. Спецификация интерфейса

d. Реализация

e. Ссылка на варианты применения

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

10. Ключ идентификации поставщика услуг

Закрытая часть идентификатора поставщика услуг используется Кодировщиком Rivetz для подписания команд. Открытая часть предоставляется для Rivetz и сопряженных устройств.

11. Ривет устройства

Апплет TEE Rivetz, который реализует наше связывание между физическими и цифровыми работами. Ривет устройства ограничивает признаки идентификации, транзакции и аттестации аппаратным обеспечением и формирует основу нашего технического предложения.

• Ривет устройства

• Контекст компонентов

• Описание компонентов

• Ответственность субъекта

• Спецификация интерфейса

• Регистрация устройства

• Генерирование ключа

• Шифрование ключом

• Расшифровка ключом

• Обработка команды

• Ссылка на варианты применения

• Замечания

a) Контекст компонентов

В настоящее время имеется две целевые платформы для размещения реализации Ривета устройства: Trustonic на Android и Intel ME для персональных компьютеров, оснащенных Windows. Обе среды обладают ограниченной обработкой и специально спроектированы простыми для безопасности и использования ресурсов.

Доверенные приложения (TA) Trustonic реализованы посредством компилятора Android NDK на C. Взаимодействие с TA осуществляется с использованием буфера в разделяемой памяти. Команды упаковывают в блок памяти, и уведомление отправляют на контроллер Trustonic для загрузки и выполнения TA. Уведомление является синхронным. Хост-приложение (обычное приложение Android) ожидает ответа. Ожидается, что доверенное приложение будет сохранять свои данные на хосте, однако контроллер Trustonic обеспечивает защищенную оболочку так, что данные могут быть открыты только при работе в TEE.

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

b) Описание компонентов

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

Имеется три главные области функциональных возможностей в Ривете устройства (доверенном приложении):

• Регистрация устройств - Это способ, которым Ривет устройства устанавливает идентификацию с Агентом регистрации (RivetzNet).

• Обработка команд - Выполнение данной команды. Это подписанная структура данных, которая происходит от Поставщика услуг.

• Примитивы безопасности - Простые функциональные возможности обеспечения безопасности, предоставляемые для использования локальным приложениям.

c) Ответственность субъекта

Название нового субъекта:

Таблица 5

Субъект	определение
Ключи учетной записи	Ключи учетной записи безопасно удерживаются Риветом устройства. Они никогда не покидают пределов доверенной среды выполнения. Они генерируются, сохраняются и применяются в безопасной оболочке, которая привязана к устройству.
Pin учетной записи	Ключи учетной записи могут быть связаны с Pin учетной записи, который используют для проверки согласия пользователя перед тем, как Ключи учетной записи применяют в какой-либо транзакции.
Полезные данные команды	Двоичный объект данных, переносимый Записью команды в Ривет устройства. Полезные данные команды интерпретируют согласно типу команды.
Запись команды	Команда Rivetz представляет собой пакет данных, предназначенный для обработки идентифицированным Риветом устройства. Он содержит команду, полезные данные и требуемые подписи для выдачи указания устройству на выполнение некоторого действия в апплете TEE Rivetz.
Подпись команды	Каждая команда, предназначенная для Ривета устройства, должна быть подписана отдающим команду Поставщиком услуг. Поставщик услуг должен быть зарегистрирован на RivetzNet. Зарегистрированный поставщик услуг будет иметь свой открытый ключ, одобренный Rivetz и распределенный всем зарегистрированным устройствам.
Запись ответа	Статус возврата и полезные данные, которые происходят из обработки Записи команды.

d) Спецификация интерфейса

i) Регистрация устройства

ii) Генерирование ключа

iii) Шифрование ключом

Адаптер TEE производит поиск названного ключа шифрования в Записи поставщика услуг

iv) Расшифровка ключом

v) Обработка команды

e) Ссылка на варианты применения

• Создание ключа - Создание пары ключей в Ривете устройства как для подписания, так и для шифрования. Actors ServiceProvider Description Основной целью Rivetz является защита и применение...

• Создание локального пользователя - Установление локального субъекта, который может авторизовать применение Ривета в случаях, когда не предоставлено авторизации поставщика услуг Actors Select/create Actors from ProductActors...

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

• Регистрация устройства на Rivetz - Прежде чем ривет сможет что-либо делать, ему необходимо зарегистрироваться на RivetzNet. Результатом регистрации является создание уникального ключа идентификации. Регистрация основана на подтверждении...

12. Полезные данные команды

Двоичный объект данных, переносимый Записью команды в Ривет устройства. Полезные данные команды интерпретируют согласно типу команды.

13. Запись команды

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

Большинство команд приведут к созданию и возвращению Записи ответа. Она будет доставлена обратно Поставщику услуг посредством Отправления Rivetz.

a) Структура данных

Таблица 6

Параметр	Тип/Размер	Описание
ID версии	integer	Тип id версии для структуры данных для совместимости
ID поставщика услуг	UUID	Уникальный идентификатор поставщика услуг, отдающего эту команду
Тип команды	integer	Идентификатор типа команды. Он определяет, как интерпретировать содержимое полезных данных
Полезные данные команды	blob	Произвольный двоичный объект данных
Подпись команды	byte(512)	Хэш команды, подписанный ключом поставщика услуг

Типы команд

Таблица 7

Имя типа	Значение	Описание
RIVETZ_DO_TEXT_CONFIRMATION		Полезные данные содержат текстовое сообщение и подписанный хэш. Строка сообщения будет отображена вместе с кнопками подтверждения и отмены. При подтверждении устройство подпишет сообщение и возвратит его.
RIVETZ_DO_IMAGE_CONFIRMATION		Полезные данные содержат изображение и подписанный хэш. Изображение будет отображено вместе с кнопками подтверждения и отмены.
RIVETZ_DISPLAY_IMAGE		Полезные данные содержат изображение, зашифрованное ключом устройства, и хэш, подписанный издателем. Изображение отображается Риветом устройства. Ничего не возвращается.
RIVETZ_DISPLAY_TEXT		Полезные данные содержат текст, зашифрованный ключом устройства, и хэш, подписанный издателем. Текст обрабатывается Риветом устройства. Ничего не возвращается.
RIVETZ_CREATE_BITCOIN_ACCOUNT		Создается новый счет bitcoin, и возвращается открытый адрес.
RIVETZ_UPDATE_SP_LIST		Полезные данные содержат идентификаторы (ID) и открытые ключи поставщиков услуг, которые были зарегистрированы Агентом регистрации (то есть Rivetz). Этот список подписывается Агентом регистрации, который зарегистрировал устройство. Другими словами, только система, которая зарегистрировала устройство, может обновлять список зарегистрированных поставщиков услуг.
RIVETZ_SIGN_VC_TXN	0x0001	Полезные данные содержат полностью укомплектованную транзакцию виртуальной валюты (Bitcoin, Litecoin, Peercoin и т.д.), которую необходимо подписать названным ключом счета Bitcoin, поддерживаемым Риветом устройства.
RIVETZ_ADD_KEY	0x0101	Полезные данные содержат данные для добавления существующего ключа к Списку ключей поставщика услуг. Рекомендуется создавать новый ключ так, чтобы его никогда не было видно в обычном мире.
RIVETZ_GET_KEY	0x0102	Полезные данные содержат запрос на извлечение открытого ключа из Записи ключа.
RIVETZ_DELETE_KEY	0x0103	Полезные данные содержат запрос на удаление Записи ключа.
RIVETZ_ENUM_KEY	0x0104	Полезные данные содержат запрос на получение списка Записей ключа.
RIVETZ_ECDSA_CREATE	0x0201	Полезные данные содержат запрос на создание открытого и закрытого ключей ECDSA. Ключ сохраняют в Записи ключа в Ривет Android.
RIVETZ_ECDSA_SIGN	0x0202	Полезные данные содержат запрос на подписание данных с использованием закрытого ключа ECDSA.
RIVETZ_ECDSA_VERIFY	0x0203	Полезные данные содержат запрос на проверку данных с использованием открытого ключа ECDSA.
RIVETZ_ECDSA_GETPUBPRV	0x0204	Полезные данные содержат запрос на получение открытого адреса виртуальной валюты (Bitcoin, Litecoin, Peercoin и т.д.) из закрытого ключа ECDSA.
RIVETZ_ECDSA_GETPUBSIG	0x0205	Полезные данные содержат запрос на получение открытого ключа ECDSA из подписи и сообщения.
RIVETZ_ECDH_ENCRYPT	0x0301	Полезные данные содержат запрос на шифрование данных с использованием ECDH.
RIVETZ_ECDH_DECRYPT	0x0302	Полезные данные содержат запрос на расшифровку данных с использованием ECDH.

Следует отметить, что не все устройства будут иметь возможность поддерживать все команды. Если команда не поддерживается, Ривет устройства возвращает NOT_SUPPORTED. См. Запись ответа.

14. Тип команды

Постоянное значение, которое указывает тип Записи команды. Оно определяет, как следует интерпретировать Полезные данные команды.

Типы команд описаны в Запись команды.

15. Подпись команды

Каждая команда, предназначенная для Ривета устройства, должна быть подписана отдающим команду Поставщиком услуг. Поставщик услуг должен быть зарегистрирован на RivetzNet. Зарегистрированный поставщик услуг будет иметь открытый ключ, одобренный Rivetz и распределенный всем зарегистрированным устройствам.

16. Ключи учетной записи

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

17. Pin учетной записи

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

18. Запись ответа

Статус возврата и полезные данные, которые происходят из обработки Записи команды.

a) Коды статуса

Таблица 8

Имя кода возврата	Описание
RETURN_INSTRUCTION_EXECUTED	Универсальный возврат для команды, которая была выполнена Риветом устройства.
RETURN_NOT_SUPPORTED	Тип команды, предоставленный в Записи команды, на этом устройстве не поддерживается
RETURN_NOT_KNOWN	Тип команды, представленный в Записи команды, неизвестен
RETURN_CONFIRMATION_OK	Запрос на подтверждение был подтвержден пользователем. Полезные данные возврата будут содержать хэш объекта подтверждения (изображения или текста), подписанный устройством
RETURN_CONFIRMATION_CANCELLED	Запрос на подтверждение был отменен пользователем
RETURN_CONFIRMATION_EXPIRED	Запрос на подтверждение не был ни подтвержден, ни отменен пользователем в пределах лимита времени

19. Адаптер ривета

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

• Адаптер ривета

• Схема

• Подкомпоненты

• Реализация

• Ссылка на варианты применения

a) Схема

b) Подкомпоненты

Адаптер ривета состоит из внешнего и внутреннего интерфейсов. Внутренний интерфейс, Адаптер TEE, отвечает за осуществление внутренней связи с доверенным приложением (Риветом устройства). Хост-адаптер предусмотрен для предоставления услуг приложениям третьих сторон.

За подробностями интерфейса и реализации, пожалуйста, обращайтесь к отдельным подкомпонентам.

Хост-адаптер - Хост-адаптер представляет интерфейс Адаптера ривета посредством разных локальных контекстов, таких как браузеры или системные службы. Предполагаются множественные реализации для разнообразных контекстов, хотя изначально это служба Android и com-процесс Windows.

Сокет-адаптер - Подключает клиентскую среду к RivetzNet.

Адаптер TEE - Этот компонент представляет собой внутренний связующий элемент, который передает команды на наше доверенное приложение, работающее на Trustonic или Intel ME.

c) Реализация

В реализации на Android Адаптер ривета проявляется как служебное приложение NDK Android. Он приспособлен запускаться при загрузке. Адаптер ривета подготавливает буферы сообщений, которые направляются на Доверенное приложение, и затем синхронно ожидает уведомления об ответном событии. Воплощение приложения Android представляет для третьей стороны ряд предназначений для запуска. Приложение, двоичные коды NDK и Доверенное приложение все упаковываются в один APK для распространения.

d) Ссылка на варианты применения

• Создание локального пользователя - Установление локального субъекта, который может авторизовать применение Ривета в случаях, когда не предоставлено авторизации поставщика услуг Actors Select/create Actors from ProductActors...

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

• Регистрация устройства на Rivetz - Прежде чем ривет сможет что-либо делать, ему необходимо зарегистрироваться на RivetzNet. Результатом регистрации является создание уникального ключа идентификации. Регистрация основана на подтверждении...

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

20. Хост-адаптер

Хост-адаптер представляет интерфейс Адаптера ривета посредством разных локальных контекстов, таких как браузеры или системные службы. Предполагаются множественные реализации для разнообразных контекстов, хотя изначально это служба Android и com-процесс Windows.

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

В конечном итоге Хост-адаптер будет предоставлять услуги Менеджера кругов, такие как резервирование или объединение.

• Хост-адаптер

• Интерфейс

• Получить указатель

• Получить хэш

• Выполнить

• Зашифровать

• Расшифровать

• Реализация на Android

• Документация предназначений для Android

• Реализация на Windows

• Ссылка на варианты применения

a) Интерфейс

Хост-адаптер работает в потенциально враждебной среде. Следовательно, обычно мы будем иметь ограниченное подтверждение того, что безопасность клиента не была нарушена. Следовательно, роль Хост-адаптера в первую очередь заключается в том, чтобы способствовать легкому доступу к Ривету устройства. Команды от Поставщика услуг, предназначенные для Ривета устройства, будут подписаны Поставщиком услуг и затем пропущены на Адаптер TEE и Ривет устройства посредством команды Execute. Команды, предназначенные для использования роли LocalServiceProvider, могут быть сформированы Хост-адаптером и затем подписаны Адаптером TEE или другим субъектом перед передачей команды на Ривет устройства.

Определенные локальные службы, такие как Encrypt (Зашифровать) и Decrypt (Расшифровать), разрешено вызывать с использованием роли LocalServiceProvider, и Хост-адаптер предоставляет интерфейс для этих служб локально для удобства наших клиентов. На некоторых платформах это может быть запрещено.

i) Получить указатель

Мы хотим защитить постоянные идентификаторы устройств от неправомерного использования. Подтвержденному поставщику услуг потребуется спросить: «Что это за устройство?». Для того, чтобы несанкционированное приложение не могло получить доступ к применимому ответу с помощью того же вопроса, мы используем Указатель устройства. Указатель устройства представляет собой идентификатор, который действителен только во время сокет-соединения с RivetzNet. При наличии Указателя устройства Поставщик услуг может запрашивать непосредственно у RivetzNet постоянный ID устройства или подавать запрос на сопряжение. Сокет-адаптер сохраняет Указатель устройства в памяти каждый раз, когда он подключается к RivetzNet.

Таблица 9

Аргументы

нет

Возврат: Указатель устройства - Кратковременный указатель на устройство, который может быть запрошен любым локальным приложением. Указатель устройства может идентифицировать текущую сессию сокета с RivetzNet и, следовательно, может быть использован для установления канала связи устройства и поиска постоянного идентификатора, ID устройства.

ii) Получить хэш

Для подписания и шифрования команд Поставщику услуг необходимо подписать хэш объекта.

Таблица 10

Аргумент	определение
Двоичный объект данных	Данные в виде неопределенного набора байтов любой длины

Возврат: Подписанный хэш -

iii) Выполнить

Передает Запись команды на Адаптер TEE и возвращает Запись ответа. Ривету потребуется получение контекста, в котором обрабатывать команду, поэтому ему необходима передача ID поставщика услуг в явном виде.

Таблица 11

Аргумент	определение
ID поставщика услуг	Уникальный идентификатор, назначенный Поставщику услуг от RivetzNet.
Запись команды	Команда Rivetz представляет собой пакет данных, предназначенный для обработки идентифицированным Риветом устройства. Он содержит команду, полезные данные и требуемые подписи для выдачи указания устройству на выполнение некоторого действия в апплете TEE Rivetz.

Возврат: Запись ответа - Статус возврата и полезные данные, которые происходят из обработки Записи команды.

iv) Зашифровать

Таблица 12

Аргумент	определение
ID поставщика услуг	Уникальный идентификатор, назначенный Поставщику услуг от RivetzNet.
Шифровать Открытый Ключ
Двоичный объект данных	Данные в виде неопределенного набора байтов любой длины

Возврат: Data Blob - Данные в виде неопределенного набора байтов любой длины

v) Расшифровать

Таблица 13

Аргумент	определение
ID поставщика услуг	Уникальный идентификатор, назначенный Поставщику услуг от RivetzNet.
Двоичный объект данных	Данные в виде неопределенного набора байтов любой длины

Возврат: Data Blob - Данные в виде неопределенного набора байтов любой длины

b) Реализация на Android

Хост-адаптер представляет собой стандартную Java-часть клиента Rivetz для Android. Он предоставляет свой интерфейс посредством Предназначений (Intents), стандартного механизма для осуществления связи между приложениями. Например:

public void connectRivet(String serviceProviderID, ByteArray instruction) {

Intent intent = new Intent(com.rivetz.RivetActionExecute)

.putExtra(com.rivet.RivetAction.EXTRA_SPID, serviceProviderID)

.putExtra(com.rivet.RivetAction.EXTRA_INSTRUCTION, instruction);

if (intent.resolveActivity(getPackageManager()) != null) {

startActivity(intent);

}

}

Каждое действие определяется как отдельный класс, унаследованный от com.rivetz.RivetAction. Например:

public class RivetActionInstruction extends RivetAction { // RivetAction расширяет Activity

@Override

protected void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

// Получить предназначение, которое начало эту деятельность

Intent intent = getIntent();

int SpID = intent.getStringExtra(com.rivet.RivetAction.EXTRA_SPID,0);

ByteArray instruction =

intent.getStringExtra(com.rivet.RivetAction.EXTRA_INSTRUCTION,0);

// вызвать соответствующую функцию JNI

result = Trustlet.RivetzActionPair(SpID,instruction);

}

Адаптер TEE определяет код JNI (Java Native Interface), который передает команду на Ривет устройства.

i) Документация предназначений для Android

Эти определения перенесены на страницы SDK для всеобщего доступа. См. Клиент Rivetz для Android.

Название нового предназначения для Android:

Таблица 14

Предназначение для Android	определение
INSTRUCT_CREATEKEY	Создать ключ определенного типа. Rivetz сохраняет ключ в локальном аппаратном зашифрованном пространстве хранения, уникальном для Поставщика услуг. Ключи получают имена для осуществления ссылок в будущем.
INSTRUCT_DECRYPT	Расшифровывает данный объект данных названным ключом
INSTRUCT_DELETEKEY	Исключает ключ, идентифицированный Именем ключа (KeyName), из наборов ключей Поставщика услуг
INSTRUCT_ENCRYPT	Шифрует данный объект данных названным ключом. Обычно это применяется с открытым ключом, загруженным посредством INSTRUCT_LOADKEY.
INSTRUCT_EXECUTE	Предоставить подписанную сервером команду на устройство. Хотя Ривету может быть поставлена задача посредством локальных неподписанных запросов, в идеале команды подписываются ключом поставщика услуг, установленным во время регистрации поставщика услуг.
INSTRUCT_GETKEY	Получает данные ключа из названного ключа, хранящегося в Ривете. Результаты будут отличаться в зависимости от Типа ключа (KeyType). Симметричные ключи и закрытые ключи возвращают зашифрованными уникальным ключом, защищенным аппаратным обеспечением устройства.
INSTRUCT_GETPOINTER	Получить временный уникальный указатель на устройство, который может быть использован для осуществления веб-запросов к Rivetz.Net
INSTRUCT_GETPUBPRV	Краткое содержание
INSTRUCT_GETPUBSIG	Краткое содержание
INSTRUCT_KEYENUM	Краткое содержание
INSTRUCT_LOADKEY	Загружает произвольный открытый ключ в набор ключей Поставщика услуг для использования с INSTRUCT_ENCRYPT
INSTRUCT_REGISTERPROVIDER	Поставщику услуг необходимо зарегистрироваться или выполнить сопряжение с устройством перед тем, как Ривет ответит на любые команды. Этот процесс по существу является мероприятием по обмену ключами при посредничестве Rivetz.net.
INSTRUCT_SIGN	Подписать двоичный объект данных названным ключом. Используемый алгоритм устанавливают при создании ключа.
INSTRUCT_SIGNTXN	Подписать валютную транзакцию названным ключом валюты (кошелька)
INSTRUCT_VERIFY	Проверить подпись для данного объекта. Код результата: Rivet.RESULT_OK обозначает, что подпись передана.

c) Реализация на Windows

TBD

d) Ссылка на варианты применения

Создание локального пользователя - Установление локального субъекта, который может авторизовать применение Ривета в случаях, когда не предоставлено авторизации поставщика услуг Actors Select/create Actors from ProductActors...

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

21. Сокет-адаптер

Подключает клиентскую среду к RivetzNet.

• Сокет-адаптер

• Контекст компонентов

• Ответственность субъекта

• Спецификация интерфейса

• Подключить (Connect)

• Отключить

• Получить указатель

• Instruct (Отдать команду)

• Ссылка на варианты применения

a) Контекст компонентов

b) Ответственность субъекта

Название нового субъекта:

Таблица 15

Субъект	определение
Rivetz Net URL	URL, по которому размещен RivetzNet
Объект сессии	Определяет ключи и другие данные для временной сессии между двумя защищенными конечными точками.

c) Спецификация интерфейса

i) Подключить

Открыть соединение с сервером. Сервер будет возвращать Указатель устройства, назначенный для этой сессии. Connect вызывается при запуске Адаптера ривета.

Аргументы: нет

Возвраты: нет

ii) Отключить

Отключиться от сервера и отбросить Указатель устройства.

Аргументы: нет

Возвраты: нет

iii) Получить указатель

Возвратить текущий Указатель устройства или null, если нет сессии.

Аргументы: нет

Возвраты: Указатель устройства - Кратковременный указатель на устройство, который может быть запрошен любым локальным приложением. Указатель устройства может идентифицировать текущую сессию сокета с RivetzNet и, следовательно, может быть использован для установления канала связи устройства и поиска постоянного идентификатора, ID устройства.

iv) Отдать команду

Принять Запись команды от RivetzNet, передать ее на ривет и асинхронно поместить Запись ответа. Каждая команда будет приходить с уникальным ID отправления, который используется RivetzNet для сопоставления команды с ответом. Следует отметить, что некоторые команды могут включать взаимодействие с пользователем посредством TUI и, следовательно, могут приводить к существенной временной задержке перед размещением ответа.

Таблица 16

Аргумент	определение
ID отправления	Уникальный идентификатор, используемый для сопоставления Записи команды, отправляемой с RivetzNet, с Записью ответа, возвращаемой Адаптером ривета
ID поставщика услуг	Уникальный идентификатор, назначенный Поставщику услуг от RivetzNet.
Запись команды	Команда Rivetz представляет собой пакет данных, предназначенный для обработки идентифицированным Риветом устройства. Он содержит команду, полезные данные и требуемые подписи для выдачи указания устройству на выполнение некоторого действия в апплете TEE Rivetz.

Возвраты	определение
ID отправления	Уникальный идентификатор, используемый для сопоставления Записи команды, отправляемой с RivetzNet, с Записью ответа, возвращаемой Адаптером ривета
Запись ответа	Статус возврата и полезные данные, которые происходят из обработки Записи команды.

d) Ссылка на варианты применения

22. Адаптер TEE

Этот компонент представляет собой внутренний связующий элемент, который передает команды на наше доверенное приложение, работающее на Trustonic или Intel ME.

a) Принципы разработки

Среды Trustonic и Intel ME следуют одинаковой основной архитектуре: хост-система сериализирует данные в буфер памяти и затем запускает TEE для обработки. Это блокирующий (синхронный) запрос. Управление возвращается, когда TEE выполняет выход, предположительно после записи данных ответа в буфер памяти.

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

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

b) Схема компонентов

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

i) Запись связи TEE

Для каждого запроса Адаптер TEE принимает входные данные, упаковывает структуру данных для TEE и вызывает execute (выполнение) в среде Доверенного апплета. Когда выполнение завершено, разделяемая память переформатируется в запись ответа. Любые данные возврата подготавливают для оригинальной вызывающей функции, и запись Поставщика услуг сохраняют обратно на диск.

c) Ответственность субъекта

Название нового субъекта:

Таблица 17

Субъект	определение
Запись поставщика услуг	Контекстная информация Поставщика услуг, предоставляемая на TEE, когда она обрабатывает команду.

d) Спецификация интерфейса

i) Обработка команды

Вызывается Сокет-адаптером, когда он получает команду от Кодировщика Rivetz. Команда представляет собой упакованный двоичный объект данных, предназначенный для обработки непосредственно TEE без синтаксического анализа.

Таблица 18

Аргумент	определение
ID поставщика услуг	Уникальный идентификатор, назначенный Поставщику услуг от RivetzNet.
Запись команды	Команда Rivetz представляет собой пакет данных, предназначенный для обработки идентифицированным Риветом устройства. Он содержит команду, полезные данные и требуемые подписи для выдачи указания устройству на выполнение некоторого действия в апплете TEE Rivetz.

Адаптер Tee загружает Запись поставщика услуг, сериализует ее в буфер памяти вместе с Записью команды и запускает TEE для обработки. После осуществления выхода TEE Запись поставщика услуг записывается обратно на диск, и двоичный объект данных с ответом возвращается на Сокет-адаптер.

ii) Зашифровать

Локальный запрос на шифрование с использованием названного ключа. Ключи шифрования принадлежат к Записи поставщика услуг и создаются с использованием команды Создание ключа.

Таблица 19

аргумент	определение
ID поставщика услуг	Уникальный идентификатор, назначенный Поставщику услуг от RivetzNet.
Имя ключа	Произвольная строка, присвоенная ключу, созданному в Ривете.
Двоичный объект данных	Данные в виде неопределенного набора байтов любой длины

iii) Расшифровать

Локальный запрос на расшифровку с использованием названного ключа.

Таблица 20

аргумент	определение
ID поставщика услуг	Уникальный идентификатор, назначенный Поставщику услуг от RivetzNet.
Имя ключа	Произвольная строка, присвоенная ключу, созданному в Ривете.
Двоичный объект данных	Данные в виде неопределенного набора байтов любой длины

e) Реализация на Android

Реализация на Android использует Java Native Interface (JNI), реализованный NDK Android.

Для осуществления связи с апплетом Trustonic, Риветом устройства, нам необходимо использовать код JNI Android. Каждое предназначение, запущенное на RivetAction, будет иметь соответствующую определенную функцию JNI, которая приводит нас в среду реализации C++.

EXTERN_C JNIEXPORT jstring JNICALL

Java_com_rivetz_Trustlet_RivetzActionPair(JNIEnv *env, jobject obj, jstring messageIn) {

/* реализация */

}

f) Ссылка на варианты применения

23. Запись поставщика услуг

Контекстная информация Поставщика услуг, предоставляемая на TEE, когда она обрабатывает команду.

a) Структура

Эта тема представлена просто для того, чтобы обратить внимание на концепции.

Таблица 21

Атрибут	определение
ID поставщика услуг	Уникальный идентификатор, назначенный Поставщику услуг от RivetzNet.
Запись ключа	Постоянный объект, который хранит ключи TEE в среде Адаптера ривета. Каждый ключ создается от имени Поставщика услуг и получает имя и правила использования.

b) Реализация

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

Детали и типы данных определены и поддерживаются в исходном коде на GitHub. См. https://github.com/rivetz/RivetzEncoder/blob/master/riv_types.h

24. Протоколы Rivetz

Протокол регистрации устройств

Протокол обработки команд

Процесс внедрения Intercede

25. Протокол обработки команд

a) Обзор

Контрагентом Ривета устройства является Кодировщик Rivetz. Кодировщик Rivetz подготавливает команду, предназначенную для выполнения определенным устройством, которая подписана и/или зашифрована Поставщиком услуг. Открытые ключи Поставщика услуг предварительно загружены в устройство во время процесса сопряжения, проведенного RivetzNet. Это позволяет Ривету устройства подтверждать подлинность происхождения запроса и, при необходимости, расшифровывать содержимое команды.

Последовательность упаковки и доставки команды является достаточно простой. Поставщик услуг генерирует Запись команды с помощью библиотек Кодировщика Rivetz. Команда включает тип, целевое устройство и полезные данные. Команда может быть закодирована ключом устройства и должна быть подписана ключом поставщика услуг. Ключ устройства извлекается из RivetzNet или непосредственно из цепочки блоков посредством поиска Записи о регистрации устройства.

26. Протокол регистрации устройства

a) Обзор

Регистрация устройств представляет собой основу, на которой стоит вся наша взаимосвязанная система.

27. Процесс внедрения Intercede

Далее приблизительно описаны этапы, которые необходимо выполнить Rivetz для того, чтобы начать применять Intercede для установки Ривета устройства.

Для изучения основ и документов см. IntercedeGroup.

• Процесс внедрения Intercede

• УСТАНОВКА КЛЮЧА:

• СБОРКА ПРИЛОЖЕНИЯ РИВЕТА УСТРОЙСТВА

• Выполнение

• Транспортный ключ

• Главный ключ персонализации

• Проверка ключа

• Ключ квитанции покупки

•

a) УСТАНОВКА КЛЮЧА:

• Сначала создают тестовый Транспортный ключ (мы будем называть его TTK).

• Генерируют три случайных 256-битных значения и сохраняют их как Доля1, Доля2, Доля3

•

• Выполняют операцию XOR между долями (Доля1 XOR Доля2 XOR Доля3) для получения TTK.

• Создают файлы для каждой из трех долей и шифруют их по отдельности тремя ключами PGP, которые Intercede отправляет на Rivetz.

• Генерируют 256-битный тестовый главный ключ персонализации (TPMK) и сохраняют его в некотором месте в коде Rivetz.

• Шифруют TPMK посредством TTK, как описано в документе Intercede, и отправляют его на Intercede по электронной почте.

• Генерируют тестовый Ключ квитанции покупки (TPRK).

• Генерируют номер «ссылки клиента» для Rosie Wallet или любого тестового поставщика услуг, который нам нужен.

• Отправляют открытую часть TPRK (мы можем назвать ее TPRPK) на Intercede.

b) СБОРКА ПРИЛОЖЕНИЯ РИВЕТА УСТРОЙСТВА

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

• Создают программное обеспечение на стороне сервера Rivetz.net, которое формирует ключ персонализации для каждого отдельного Ривета устройства.

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

• Включение библиотеки клиента MyTAM в наше реальное приложение (Адаптер ривета) для оказания помощи в установке Ривета устройства и пакета персонализации.

c) Выполнение

i) Транспортный ключ

Для формирования случайных значений, доли1, доли2, доли2:

tr -cd [:alnum:] < /dev/urandom | head -c $(tr -cd 0-9 < /dev/urandom | head -c 1) | sha256sum | tr -d ' -'

Это должно выглядеть как: a9f51566bd6705f7ea6ad54bb9deb449f795582d6529a0e22207b8981233ec58.

Эта команда направляет случайные данные из ядра Linux через инструмент обработки текста (tr), который вытаскивает цифробуквенные символы, обрезает результат до случайного количества символов (с заголовком) и затем направляет это в sha256sum. Наконец, она снова использует tr для удаления замыкающих пробелов и дефисов

Это делают трижды и объединяют результаты операцией XOR с использованием вызова командной строки Python:

python -c 'print "{:x}".format(

int("bb65b75d83d82065b17929affd23e8f26f9e134ff90646e1fd087eb4339b89fe",16) ^

int("e5568e87e6fd44b373fa92c361f5c5c37ce5f4ddf97cefe1177b3d3720912854",16) ^

int("a9f51566bd6705f7ea6ad54bb9deb449f795582d6529a0e22207b8981233ec58",16))'

Это в результате дает: f7c62cbcd842612128e96e2725089978e4eebfbf655309e2c874fb1b01394df2

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

Следует отметить, что все эти файлы представлены в шестнадцатеричном формате ASCII. Для преобразования в двоичный выполняют

cat share1 | xxd -r -p > share1.bin

Собирая это все вместе

tr -cd [:alnum:] < /dev/urandom | head -c $(tr -cd 0-9 < /dev/urandom | head -c 1) | sha256sum | tr -d ' -' > share1

tr -cd [:alnum:] < /dev/urandom | head -c $(tr -cd 0-9 < /dev/urandom | head -c 1) | sha256sum | tr -d ' -' > share2

tr -cd [:alnum:] < /dev/urandom | head -c $(tr -cd 0-9 < /dev/urandom | head -c 1) | sha256sum | tr -d ' -' > share3

python -c 'print "{:x}".format(int(open("share1","r").read(),16) ^ int(open("share2","r").read(),16) ^ int(open("share3","r").read(),16))' > TTK

Затем для каждого фрагмента:

gpg --import recipient.asc

cat share1 | xxd -r -p > share1.bin

gpg -o encrypted_share_for_recipient.gpg --encrypt -r <KEY-ID> share1.bin

ii) Главный ключ персонализации

1. генерирование случайного числа

2. преобразование в двоичный формат

3. шифрование Транспортным ключом и затем преобразование в шестнадцатеричный формат для доставки на Intercede

tr -cd [:alnum:] < /dev/urandom | head -c $(tr -cd 0-9 < /dev/urandom | head -c 1) | sha256sum | tr -d ' -' > TPMK

cat TPMK | xxd -r -p > TPMK.bin

openssl enc -aes-256-ecb -in TPMK.bin -nopad -K `cat TTK` | xxd -p -c 256 > TPMK.enc.hex

iii) Проверка ключа

Контрольное значение (KCV) также может быть вычислено и отправлено на Intercede. Необязательное контрольное значение гарантирует, что Главный ключ персонализации является верным, когда импортирован в HSM Intercede - контрольное значение вычисляют следующим образом.

• Применяют (незашифрованный) Главный ключ персонализации для шифрования одного блока (16 байт) бинарных нулей. (Применяют режим ECB, без заполнения).

• Первые 3 байта выходных данных являются контрольным значением (KCV). KCV передают на Intercede.

• Процесс импорта ключа в MyTAM на Intercede проверит KCV (если предоставлен) и обеспечит дополнительную проверку того, что обмен ключами был выполнен верно.

echo 00000000000000000000000000000000 | xxd -p -r | openssl enc -aes-256-ecb -nopad -K `cat TPMK` | xxd -p -c 256 | cut -b -6 > TPMK.kcv

iv) Ключ квитанции покупки

Как полагается, он должен имитировать ключ квитанции Google Play для покупок внутри приложений. Ключ применяют для подписания SUID устройства во время обеспечения. Intercede использует его как квитанцию «покупки».

openssl genrsa -out TPRK.pem 2048

openssl rsa -in TPRK.pem -pubout > TPRPK.pem

Это генерирует 2048-битный ключ RSA в файле TPRK.pem и затем извлекает открытый ключ в TPRPK.pem, который надлежит отправить на Intercede.

С openssl.org: «Форма PEM представляет собой формат по умолчанию: он состоит из формата DER, закодированного посредством base64 с дополнительными строками заголовка и примечания. На входе также принимаются закрытые ключи в формате PKCS#8».

Из документации Google Play: «Закодированный посредством Base64 RSA открытый ключ, сгенерированный Google Play, имеет двоично закодированный формат X.509 subjectPublicKeyInfo DER SEQUENCE. Это тот же открытый ключ, который применяется при лицензировании Google Play».

openssl genrsa -out TPRK.pem 2048

openssl rsa -in TPRK.pem -outform der -pubout > TPRPK.der

Это обеспечивает бинарный формат ключа

28. Варианты применения Rivetz

Rivetz предоставляет партнерам SDK для выполнения простых, но особо важных транзакций с устройством. Это расширяет аутентификацию сообщений до подписания Bitcoin. Интерфейс представляет собой системный интерфейс, но некоторые службы будут требовать от пользователя ввода PIN, визуального подтверждения и т.д.

a) Варианты применения

Название нового варианта применения:

Таблица 22

Вариант применения	определение
Создание счета Bitcoin	Генерирование нового id счета кошелька в аппаратном обеспечении устройства
Создание ключа	Создание пары ключей в Ривете устройства как для подписания, так и для шифрования.
Создание локального пользователя	Установление локального субъекта, который может авторизовать применение Ривета в случаях, когда не предоставлено авторизации Поставщика услуг.
Расшифровка чего-либо	При получении зашифрованного объекта и имени ключа осуществляется расшифровка объекта либо для отображения в TUI, либо для возврата запросчику.
Шифрование чего-либо	Rivetz предоставляет механизмы для шифрования текста или изображений, но ожидает, что партнеры спроектируют интерфейс для своей службы, будь то приложение для передачи сообщений или какое-либо другое.
Регистрация устройства на Rivetz	Прежде чем ривет сможет что-либо делать, ему необходимо зарегистрироваться на RivetzNet. Результатом регистрации является создание уникального ключа идентификации.
Регистрация устройства у поставщика услуг	Поставщику услуг необходимо зарегистрировать свои ID поставщика услуг и открытый ключ идентификации на устройстве, прежде чем это устройство станет отвечать на какие-либо запросы.
Регистрация поставщика услуг на Rivetz	Любому, кто хочет использовать систему шифрования Rivetz, необходимо зарегистрироваться в качестве Поставщика услуг
Отправка защищенного запроса на подтверждение	Упаковка короткого сообщения, которое будет доставлено на целевое конечное устройство и отображено пользователю посредством защищенного отображения, если доступно. Передаваемое подписывается обоими способами, чтобы гарантировать, что подтверждение действительно. Сообщение может представлять собой изображение или текст.
Подписание транзакции Bitcoin	При получении полностью сформированной транзакции bitcoin (где исходящим счетом владеет аппаратное обеспечение целевого устройства) подписание транзакции и ее возврат. В большинстве случаев это также должно включать запрос у пользователя подтверждения с использованием защищенного отображения, если доступно, или по меньшей мере обычного отображения в ином случае.
Подписание чего-либо	При получении названного ключа и ссылки на объект возврат подписанного хэша объекта
Восстановление пользователем забытого PIN устройства	Краткое содержание
Проверка чего-либо	Проверка подписи на объекте посредством названного или данного ключа.

b) Участники

Название нового участника:

Таблица 23

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

29. Диспетчер доверенных приложений

Субъект, который может одобрять доверенное приложение и загружать его в доверенную среду выполнения (TEE)

a) Определение

В мире Trustonic Giesecke And Devrient и Intercede Group являются установившимися TAM.

30. Пользователь услуги

Пользователь услуги - это некто, кто взаимодействует с основным признаком/функцией нашей службы.

a) Определение

31. Системный администратор

Системный администратор занимается установкой, настройкой и поддержкой нашей службы

a) Определение

32. Представитель учетной записи

Сотрудник Rivetz, ответственный за взаимоотношения с Поставщиком услуг

a) Определение

33. Поставщик услуг

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

Определение

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

a) Демонстративный поставщик услуг

Ясно, что нам необходимо иметь ID поставщика услуг, который можно легко передать разработчикам для предварительного тестирования и проведения опытных работ. Мы уже занимаемся этим, но со случайным UUID, который внедрил Марк Хоблит (Mark Hoblit). Например:

Intent intent = new Intent(Rivet.RIVET_INTENT)

.putExtra(Rivet.EXTRA_INSTRUCT, Rivet.INSTRUCT_CREATEKEY)

.putExtra(Rivet.EXTRA_SPID, "98f88054-f98c-440c-81aa-77fa70a31116-fbca7c00-0602-4c1f-a354-820ae9ec46b9")

.putExtra(Rivet.EXTRA_KEYTYPE, Rivet.KEYTYPE_ECDSA_DEFAULT)

.putExtra(Rivet.EXTRA_KEYNAME,"MyKey");

Следует отметить, что устройство, активированное посредством демонстративного SPID, приведет к выплате лицензионного платежа Intercede и Trustonic точно так же, как и стандартный ривет.

34. Регистрация поставщика услуг на Rivetz

Любому, кто хочет использовать систему шифрования Rivetz, необходимо зарегистрироваться в качестве Поставщика услуг

Начальная регистрация представляет собой просто заполнение формы на RivetzNet (http://rivetz.com/docs/registration.html).

a) Участники

Поставщик услуг, Представитель учетной записи

b) Описание

1. Поставщик услуг создает локальные открытые/закрытые ключи

2. Поставщик услуг идет на HTTP форму на rivetz.com (http://rivetz.com/docs/registration) и вводит следующую информацию:

• Название компании

• Контакты: Имя, Фамилия, Должность, адрес электронной почты, телефон

• Веб-сайт компании

• Адрес компании: Улица, город, штат/провинция, страна

3. Поставщик услуг нажимает «Я принимаю» условия соглашения о предоставлении услуг.

4. Поставщик услуг выбирает пароль и подтверждает его (именем пользователя будет данный контактный адрес электронной почты)

• Мы говорим ему, что он может быть позже заменен аутентификацией устройства

5. У поставщика услуг запрашивают выгрузить открытый ключ

• Это можно пропустить и сделать позже

• Нам также следует предоставить более безопасные способы получения открытого ключа, чем эта выгрузка

6. Если ключ предоставлен, то генерируют SPID (ID поставщика услуг) и передают по электронной почте клиенту

• Если ключ не предоставлен, по электронной почте отправляют подтверждение с сообщением ожидания и указаниями по предоставлению ключа.

7. Представитель учетной записи будет получать уведомление о новой регистрации

• В этот момент данные могут быть загружены на Sales Force, и Представитель учетной записи может принять решение о личном отслеживании.

i) Вариант: Новый Поставщик услуг возвращается для предоставления ключа

1. Поставщик услуг входит в систему с помощью адреса электронной почты и пароля

2. Поставщик услуг замечает состояние «ожидания» учетной записи

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

4. Когда ключ передан, создают SPID и передают по электронной почте на контактный адрес электронной почты Поставщика услуг

5. Учетная запись более не является ожидающей

6. Представителя учетной записи уведомляют об изменениях в учетной записи.

c) Замечания

35. Восстановление пользователем забытого PIN устройства

Краткое содержание

a) Участники

Select/create Actors from ProductActors

b) Описание

c) Замечания

36. Проверка чего-либо

Проверка подписи на объекте посредством названного или данного ключа.

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

a) Участники

Поставщик услуг

b) Описание

c) Замечания

WebHome > ProductViewpoint > ProductUseCases > RivetzUseCases > CreateKey

37. Создание ключа

Создание пары ключей в Ривете устройства как для подписания, так и для шифрования.

a) Участники

Поставщик услуг

b) Описание

Основной целью Rivetz является обеспечение безопасности и применение ключей на конечных устройствах. Ключи шифрования (приватности) или ключи подписания (идентификации) генерируют с использованием криптографических инструментов в TEE и безопасно сохраняют на устройстве с использованием ключа хранилища TEE. Ключи адреса Bitcoin поддерживаются аналогично, но имеют особенности, см. Создать счет Bitcoin.

Все ключи создают в контексте Поставщика услуг. Другими словами, каждый ключ хранят вместе с ID поставщика услуг, который запросил его создание. Каждому ключу дают имя, которое является уникальным в контексте ID поставщика услуг.

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

• требование подписанного запроса для применения ключа создателем ключа (Поставщиком услуг)

• требование подтверждения пользователя для применения ключа посредством доверенного интерфейса пользователя (TUI)

• требование отображения результата в TUI

Для получения дополнительной информации о том, что означает получение отображения результата в TUI, см. Расшифровка чего-либо и Проверка чего-либо.

c) Замечания

38. Создание счета Bitcoin

Генерирование нового id счета кошелька в аппаратном обеспечении устройства

a) Участники

Поставщик услуг

b) Описание

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

При создании адреса Bitcoin Поставщик услуг должен указать, требует ли счет подтверждения в TUI для подписания транзакции.

c) Замечания

39. Шифрование чего-либо

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

Ключи расшифровки могут быть помечены так, чтобы требовать отображения в TUI расшифрованного объекта.

MJS> Следует отметить, что это отличается от требования подтверждения в TUI.

a) Участники

Пользователь услуги, Поставщик услуги

b) Описание

Адаптеру ривета будет необходимо иметь открытый ключ целевого устройства, который или предоставляется непосредственно Поставщиком услуг, или ранее записан в Ривете устройства во время сопряжения устройств. На стороне шифрования Ривет устройства привлекать не нужно, поскольку операция представляет собой операцию только с открытым ключом. Независимо от этого на стороне шифрования входные данные в функцию на интерфейсе Хост-адаптера (или Кодировщика Rivetz) включают:

* ID целевого устройства или статический открытый ключ шифрования целевого устройства (ключ шифрования должен быть известен субъекту, выполняющему шифрование) * (Необязательные) Данные, которые необходимо зашифровать

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

c) Замечания

Отправка защищенного запроса на подтверждение

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

a) Участники

Поставщик услуг, Пользователь услуги

b) Описание

Ценность защищенного запроса на подтверждение состоит в том, что известно, что имеется очень малая вероятность (если вообще имеется) того, что сообщение может быть подтверждено каким-либо другим устройством, кроме предназначенного. И еще в том, что устройство отображает подтверждение, которое может прийти только из указанного источника. Для достижения этого требуется регистрация ключей как от устройства и поставщика услуг, так и TEE на устройстве, чтобы гарантировать, что ничего нежелательного не происходит, когда сообщение обрабатывается и представляется для отображения в диком крае сети (пользовательских устройств).

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

c) Замечания

Подписание чего-либо

При получении названного ключа и ссылки на объект возврат подписанного хэша объекта

a) Участники

Поставщик услуг

b) Описание

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

c) Замечания

42. Регистрация устройства на Rivetz

Прежде чем ривет сможет что-либо делать, ему необходимо зарегистрироваться на RivetzNet. Результатом регистрации является создание уникального ключа идентификации.

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

a) Участники

Диспетчер доверенных приложений

b) Описание

См. Протокол регистрации устройств

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

1. Устройство создает локальные открытые/закрытые ключи

Эти ключи должны быть локально сохранены как ключ идентификации для поставщика услуг «Rivetz».

2. Устройство выполняет вызов HTTP REST на rivetz.net, запрашивая регистрацию с подписью открытым ключом в качестве уникального идентификатора

RivetzNet необходимо проверить действительность запроса посредством протокола, предоставляемого Диспетчером доверенных приложений (TBD).

3. Устройство принимает ответ, показывающий, что оно теперь зарегистрировано (или показывающий, что оно было зарегистрировано ранее) со своим уникальным ID устройства и именем очереди RabbitMQ для прослушивания входящих команд

4. Устройство запускает RabbitMQ для прослушивания входящих команд в указанной очереди

c) Замечания

43. Подписание транзакции Bitcoin

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

a) Участники

Поставщик услуг, Пользователь услуги

b) Описание

c) Замечания

44. Создание локального пользователя

Установление локального субъекта, который может авторизовать применение Ривета в случаях, когда не предоставлено авторизации Поставщика услуг

a) Участники

Select/create Actors from ProductActors

* Ривет устройства

* Адаптер TEE

* Rivetz.net (Необязательно)

b) Описание

Для обеспечения быстрого и легкого использования Ривета устройства Ривет устройства может разрешать создание «локального пользователя». Локальный пользователь определяется как субъект, который не является авторизованным Поставщиком услуг, но которому позволено осуществлять доступ к Ривету устройства с некоторыми полномочиями. Хотя Поставщику услуг может быть позволено создавать ключи bitcoin и управлять ими, и предоставлять другие услуги, Локальному пользователю может быть разрешено только выполнять определенные операции. Эти операции могут включать:

* Создание и использование ключей шифрования

* Создание и использование ключей подписи

Свойства локального пользователя являются следующими:

- Авторизация для Локального пользователя изначально будет проведена на локальной платформе, но позже может быть защищена где-либо еще

- Локального пользователя необязательно авторизует Rivetz.net

- Локальный пользователь может быть скрыт от настоящего пользователя-человека или приложения. Управление им может осуществляться внутри Адаптера ривета

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

- С точки зрения приложения Хост-адаптер предоставляет интерфейс, который делает понятие Локального пользователя прозрачным, за исключением того, что ключи, связанные с Локальным пользователем, являются недоступными через любой интерфейс, кроме как через Хост-адаптер

Следует осторожно относиться к названию «локальный пользователь», поскольку это пользователь с точки зрения Ривета устройства, но необязательно с внешней точки зрения. Одна идея состоит в том, что локального пользователя обслуживает Адаптер TEE. Адаптер TEE устанавливает совместно используемый секретный ключ с Риветом устройства или создает открытый ключ, который авторизует локального пользователя на Ривете устройства.

c) Замечания

45. Локальный пользователь

Это субъект, который может осуществлять доступ к Ривету устройства без участия со стороны формального Поставщика услуг. То есть это роль, которая отличается от обычного поставщика услуг, и можно ожидать, что может существовать разный Локальный пользователь для каждого Ривета устройства, который может осуществлять доступ только к одному конкретному Ривету устройства.

Следует принять определенные решения относительно обеспечения Локального пользователя, но одна возможность состоит в том, что Rivetz.net авторизует Локального пользователя в ходе этапа обеспечения таким же образом, как это может быть сделано с обычным Поставщиком услуг (например, посредством операции «сопряжения»). Если это такой случай, Rivetz может по-прежнему сохранять контроль над тем, кто может осуществлять доступ к услугам Ривета устройства, а также, в перспективе, обеспечивать некоторую надежную защиту доступа к роли Локального пользователя (гарантируя, что авторизация для Локального пользователя надежно защищена и находится под управлением некоторого доверенного субъекта).

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

• Локальный пользователь

46. Регистрация устройства у поставщика услуг

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

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

a) Участники

Поставщик услуг

b) Описание

1. Локальное приложение поставщика услуг отправляет запрос на Адаптер ривета на получение указателя устройства

2. Устройство выполняет вызов HTTP REST на RivetzNet с новым указателем устройства и ID устройства (ЗАМЕЧАНИЕ: здесь необходима аутентификация... можно использовать открытый ключ или ключ API, подобно вышеописанному), а также открытым ключом

3. Ответ с сервера содержит очередь RabbitMQ для ожидания приходящего открытого ключа поставщика услуг

4. Поставщик услуг передает указатель устройства на свои серверы

5. Поставщик услуг выполняет вызов HTTP REST с указателем устройства и открытым ключом SP

6. Ответ поставщику услуг включает открытый ключ устройства

7. Открытый ключ поставщика услуг передают на устройство

c) Замечания

47. Расшифровка чего-либо

При получении зашифрованного объекта и имени ключа осуществляется расшифровка объекта либо для отображения в TUI, либо для возврата запросчику.

a) Участники

Поставщик услуг

b) Описание

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

c) Замечания

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

при подготовке к доставке электронной транзакции в сети цепочки блоков реализацию процесса проверки сохранности устройства в качестве части транзакции, включающую:

выполнение внутреннего подтверждения сохранности среды выполнения устройства из корня доверия в устройстве пользователя и

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

причем проверка сохранности подписи основана на определении того, находится ли среда выполнения устройства в известном хорошем состоянии, при этом:

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

2. Способ по п. 1, отличающийся тем, что проверка сохранности подписи включает:

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

создание в пределах среды выполнения устройства команды от корня доверия в устройстве пользователя;

затребование первой электронной подписи, которая соответствует команде корня доверия, таким образом проверку сохранности подписи применяют к транзакции цепочки блоков; и

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

сравнение подписи с ранее записанным опорным значением;

если подпись соответствует ранее записанному опорному значению - предоставление разрешения на продолжение транзакции; и

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

3. Способ по п. 1, отличающийся тем, что проверка сохранности подписи включает:

предоставление устройством электронной подписи на основе определения того, находится ли среда выполнения устройства в известном хорошем состоянии;

предоставление разрешения на продолжение транзакции, если устройство предоставляет электронную подпись;

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

4. Способ по п. 2, отличающийся тем, что внешний процесс дополнительно включает применение функции N или M криптографических ключей для подтверждения по меньшей мере одного из следующего: намерение пользователя соответствует предопределенным требованиям, или сохранность устройства соответствует предопределенным требованиям, или дополнительный процесс соответствует предопределенным требованиям.

5. Способ по п. 2, отличающийся тем, что опорное значение генерируют во время процесса регистрации, выполняемого владельцем платформы устройства.

6. Способ по п. 2, отличающийся тем, что опорное значение генерируют на основе сертификата выпуска, приписанного устройству, причем сертификат выпуска генерируется производителем или создателем устройства, производителем или создателем среды выполнения устройства и/или производителем или создателем приложения, находящегося на устройстве.

7. Способ по п. 2, отличающийся тем, что опорное значение содержит подпись по меньшей мере одного из производителя или создателя устройства, производителя или создателя среды выполнения устройства и/или производителя или создателя приложения, находящегося на устройстве.

8. Способ по п. 2, отличающийся тем, что внешний процесс третьей стороны возвращает маркер в ответ на запрос проверки транзакции.

9. Способ по п. 2, отличающийся тем, что дополнительно предоставляют разрешение на выполнение электронной транзакции в течение определенного периода времени, если подпись не соответствует ранее записанному опорному значению.

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

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

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

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

14. Способ по п. 1, отличающийся тем, что дополнительно включает уведомление третьей стороны о транзакции, причем в ответ на уведомление третья сторона записывает транзакцию и состояние устройства.

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

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

17. Реализуемая на компьютере система проверки сохранности устройства пользователя в коммуникационной сети цепочки блоков, содержащая:

коммуникационную сеть цепочки блоков;

устройство пользователя в сети цепочки блоков;

электронную транзакцию в сети цепочки блоков;

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

внутреннее подтверждение сохранности среды выполнения устройства, выполненное из корня доверия в устройстве;

электронную подпись, таким образом проверку сохранности подписи применяют к транзакции цепочки блоков;

причем проверка сохранности подписи основана на определении того, находится ли среда выполнения устройства в известном хорошем состоянии, при этом:

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