СПОСОБ И СООТВЕТСТВУЮЩАЯ СИСТЕМА ДЛЯ УПРАВЛЕНИЯ ЗАЩИЩЕННЫМ ВЫПОЛНЕНИЕМ ОПЕРАЦИЙ ВЗАИМОСВЯЗАННЫМИ УСТРОЙСТВАМИ Российский патент 2025 года по МПК H04L9/40 

Область техники, к которой относится изобретение

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

Предпосылки создания изобретения

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

[003] В таком контексте взаимосвязанных устройств было разработано множество аппаратных и программных решений для обеспечения защищенной передачи данных по сетям. Например, в документе US 2012117380 A1 раскрыты способ предоставления авторизации для доступа к компьютерному объекту в системе автоматизации, компьютерная программа и система автоматизации. Безопасность обмена данными по сети от вторжений (недоверенной стороны) была повышена за счет использования шифрования данных. Например, была разработана «операционная система богатой среды исполнения» REE (например, как Android^TM). Однако этого не всегда достаточно для предотвращения (физических) вторжений и обеспечения целостности данных. Таким образом, для повышения безопасности была разработана физическая защита блоков обработки или по меньшей мере их части. Например, технология, основанная на концепции «доверенная среда исполнения» TEE, использующая как аппаратное, так и программное обеспечение для защиты данных, была разработана промышленностью (например, технология ARM TrustZone компании ARM Holdings, см. также ссылки [1] и [2]). Доверенная среда исполнения TEE - это защищенная область процессора: как изолированная среда исполнения она гарантирует защиту кода и данных, загруженных внутрь, в отношении целостности и конфиденциальности конфиденциальных данных.

[004] TEE использует защищенные аппаратные анклавы. Защищенный анклав - это защищенная область памяти, действующая как TEE для обработки конфиденциальных данных внутри устройства для обработки. Защищенный анклав выглядит как непрозрачная коробка для остальной части устройства и других процессов, работающих на устройстве: нет возможности просмотреть какие-либо данные или код внутри анклава извне. Например, при анализе запроса приложения от клиентского драйвера устройство для обработки определяет, содержит ли запрос какие-либо операции с зашифрованными данными, требующие использования защищенного анклава. Для запросов, для которых требуется доступ к защищенному анклаву: (i) клиентский драйвер отправляет ключи шифрования на уровне столбцов, необходимые для операций, в защищенный анклав (по защищенному каналу), (ii) затем клиентский драйвер отправляет запрос на выполнение по зашифрованным параметрам запроса. Во время обработки запроса данные или ключи шифрования на уровне столбцов не отображаются в виде обычного текста за пределами защищенного анклава (устройство для обработки делегирует криптографические операции и вычисления для зашифрованных столбцов в защищенный анклав). Защищенный анклав (внутри устройства для обработки) может получить доступ к конфиденциальным данным, хранящимся в зашифрованном столбце базы данных, и к соответствующим ключам шифрования на уровне столбцов в виде открытого текста. Перед отправкой запроса, включающего вычисления анклава, в устройство для обработки, клиентский драйвер внутри приложения должен убедиться, что защищенный анклав является подлинным анклавом, основанным на заданной технологии (например, «Безопасность на основе виртуализации» VBS), и код, работающий внутри анклава, был подписан для работы внутри анклава.

[005] Кроме того, были разработаны специальные протоколы связи/верификации для повышения безопасности передачи данных (см. [3]) по сетям связи. Например, существуют протоколы верификации, такие как «доказательство с нулевым разглашением» ZKP (см. [4]), для проверки в автономном режиме действительности цифровой подписи (доказательства подписи) цифрового артефакта (см., например, [5], [6]).

[006] Также существуют протоколы ZKP для подписания цифрового артефакта новым ключом без учета значения ключа, т. е. без изучения того, как положительно реагировать на доказательство подписи, т. е. через «слепые» (см. [6], [7]), эффективные (см. [8], [9], [10]) или делегированные (см. [11]) подписи.

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

Краткое описание изобретения

[008] Согласно одному аспекту настоящее изобретение относится к способу управления множеством устройств с помощью сервера, подключенного к базе данных, причем каждое устройство оснащено блоком обработки, блоком связи и аппаратными средствами, основанными на концепции доверенной среды исполнения (TEE), имеющими память и защищенным образом подключенными к блоку связи посредством предназначенного пути защищенных аппаратных средств, и управляется соответствующим контроллером, причем блоки связи выполнены с возможностью защищенной связи друг с другом по беспроводной или проводной линии связи между двумя пунктами для автономной связи, и сервер выполнен с возможностью защищенной связи с каждым блоком связи устройства по проводной или беспроводной сети связи для связи в режиме «онлайн», сервер и блоки связи выполнены с возможностью передачи данных с использованием зашифрованных протоколов, сервер и TEE каждого устройства выполнены с возможностью выдачи ответа на притязание на проверку действительности посредством протокола доказательства с нулевым разглашением (ZKP) и генерирования и проверки действительности одноразовой цифровой подписи владения и ее соответствующего притязания на проверку действительности подписи владения,

при этом:

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

в случае автономной передачи токена, принадлежащего контроллеру A устройства, другому контроллеру B другого устройства, контроллер A сначала отправляет запрос на автономную передачу, содержащий уникальный идентификатор токена и автономную подпись TEE одноразового использования доверенной среды исполнения устройства контроллера A, посредством связи в режиме «онлайн» на сервер с помощью блока связи устройства, после приема указанного запроса на автономную передачу сервер проверяет, что уникальный идентификатор токена хранится в базе данных с соответствующим притязанием на владение токеном, а затем отправляет указанное притязание на владение токеном контроллеру A, после приема и верификации ответа о притязании на владение токеном от контроллера A сервер верифицирует действительность автономной подписи TEE одноразового использования, в случае если указанная автономная подпись TEE одноразового использования является действительной, сервер заменяет притязание на владение токеном, соответствующее уникальному идентификатору токена, притязанием на владение TEE, соответствующим автономной подписи TEE одноразового использования, и отправляет обратно подтверждающее сообщение, указывающее на успешную замену притязания на владение токеном, вместе с данными, необходимыми для TEE устройства контроллера A, чтобы начать выполнение токена, в случае если указанная автономная подпись одноразового использования является недействительной, сервер отправляет обратно соответствующее сообщение об ошибке, соответствующее недействительной автономной подписи одноразового использования, контроллеру A;

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

(i) токен подписан сервером,

(ii) владельцем токена является контроллер A, и

(iii) токен работает в доверенной среде исполнения устройства контроллера A;

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

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

[009] На этапе (ii) вышеупомянутого способа TEE устройства контроллера B может проверить, что владельцем токена является контроллер A, посредством протокола доказательства с нулевым разглашением ZKP на устройстве контроллера B в автономном режиме связи с помощью блока связи устройства контроллера А.

[010] На этапе (iii) вышеупомянутого способа TEE устройства контроллера B может проверить, что токен работает в доверенной среде исполнения устройства контроллера A, посредством динамической синхронизации/реконструкции состояния систем и протокола ZKP для подписи TEE на устройстве контроллера B в автономном режиме связи с помощью блока связи устройства контроллера A.

[011] В вышеупомянутом способе контроллер A может изменить притязание на владение токеном для работающего токена в пользу контроллера B посредством забывчивых вычислений на устройстве контроллера A в автономном режиме связи с помощью блока связи устройства контроллера B.

[012] Согласно вышеупомянутому способу, при остановке работы автономного токена посредством TEE устройства контроллера B:

- TEE устройства контроллера B может генерировать проверяемую подпись одноразового использования, доказывающую, что автономный токен был остановлен, и содержащую доказуемую проверку оригинальной автономной подписи TEE одноразового использования, и устройство контроллера B может генерировать одну подпись притязания на владение одноразового использования;

- контроллер B может добавить в запрос на передачу проверяемую подпись одноразового использования, доказуемую проверку оригинальной автономной подписи TEE одноразового использования и подпись притязания на владение одноразового использования, а также рассылает запрос на передачу в режиме «онлайн» на сервер; и

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

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

верификации действительности принятой подписи одноразового использования, а затем, если она является действительной, оспаривания права владения посредством принятой оригинальной автономной подписи TEE одноразового использования, затем

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

[013] В случае если TEE устройства контроллера A не запускает работу токена или останавливает работу токена до его передачи на устройство контроллера B,

TEE устройства контроллера A может генерировать проверяемую подпись одноразового использования, доказывающую, что автономный токен был остановлен, а устройство контроллера A может генерировать подпись притязания на владение одноразового использования, соответствующую новому притязанию на владение токеном для контроллера A;

контроллер A может отправлять на сервер запрос на возврат, указывающий серверу вернуть токен в режим «онлайн» вместе с проверяемой подписью одноразового использования и подписью притязания на владение одноразового использования;

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

верификации того, что токен действительно находится в автономном режиме, затем

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

[014] Согласно вышеупомянутому способу, в случае передачи в режиме «онлайн» токена, принадлежащего контроллеру A устройства, другому контроллеру B другого устройства, передача может включать:

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

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

- отправку контроллером А запроса на передачу на сервер с указанием уникального идентификатора токена и принятой подписи притязания на владение одноразового использования контроллера B,

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

- после приема и верификации ответа о владении от контроллера A сервер верифицирует действительность подписи владения одноразового использования контроллера B в запросе на передачу, и

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

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

[015] Согласно другому аспекту настоящее изобретение относится к системе для управления множеством устройств с помощью сервера, подключенного к базе данных, причем каждое устройство оснащено блоком обработки, блоком связи и аппаратными средствами, основанными на концепции доверенной среды исполнения (TEE), имеющими память и защищенным образом подключенными к блоку связи посредством предназначенного пути защищенных аппаратных средств, и управляется соответствующим контроллером, причем блоки связи выполнены с возможностью защищенной связи друг с другом по беспроводной или проводной линии связи между двумя пунктами для автономной связи, и сервер выполнен с возможностью защищенной связи с каждым блоком связи устройства по проводной или беспроводной сети связи для связи в режиме «онлайн», сервер и блоки связи выполнены с возможностью передачи данных с использованием зашифрованных протоколов, сервер и TEE каждого устройства выполнены с возможностью выдачи ответа на притязание на проверку действительности посредством протокола доказательства с нулевым разглашением (ZKP) и генерирования и проверки действительности одноразовой цифровой подписи владения и ее соответствующего притязания на проверку действительности подписи владения,

при этом:

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

для осуществления автономной передачи токена, принадлежащего контроллеру A устройства, другому контроллеру B другого устройства,

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

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

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

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

(i) токен подписан сервером,

(ii) владельцем токена является контроллер A, и

(iii) токен работает в доверенной среде исполнения устройства контроллера A;

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

TEE устройства контроллера B останавливает работу токена и генерирует доказательство остановки, а затем контроллер B отправляет в режиме «онлайн» запрос на передачу, содержащий уникальный идентификатор токена, доказательство остановки и измененное притязание на владение токеном, на сервер, и

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

[016] В вышеупомянутой системе для осуществления операции проверки (ii) того, что владельцем токена является контроллер A, TEE устройства контроллера B может проверить, что владельцем токена является контроллер A, посредством протокола доказательства с нулевым разглашением на устройстве контроллера B в автономном режиме связи с помощью блока связи устройства контроллера А.

[017] Для осуществления операции проверки (iii) того, что токен работает в доверенной среде исполнения устройства контроллера A, TEE устройства контроллера B может проверить, что токен работает в доверенной среде исполнения устройства контроллера A, посредством динамической синхронизации/реконструкции состояния систем и протокола ZKP для подписи TEE на устройстве контроллера B в автономном режиме связи с помощью блока связи устройства контроллера A.

[018] Согласно вышеупомянутой системе контроллер A может изменить притязание на владение токеном для работающего токена в пользу контроллера B посредством забывчивых вычислений на устройстве контроллера A в автономном режиме связи с помощью блока связи устройства контроллера B.

[019] Согласно системе, при остановке работы автономного токена посредством TEE устройства контроллера B,

- TEE устройства контроллера B может генерировать проверяемую подпись одноразового использования, доказывающую, что автономный токен был остановлен, и содержащую доказуемую проверку оригинальной автономной подписи TEE одноразового использования, и устройство контроллера B может генерировать подпись притязания на владение одноразового использования;

- контроллер B может добавить в запрос на передачу проверяемую подпись одноразового использования, доказуемую проверку оригинальной автономной подписи TEE одноразового использования и подпись притязания на владение одноразового использования, а также может рассылать запрос на передачу в режиме «онлайн» на сервер с помощью блока связи устройства контроллера B; и

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

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

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

[020] В вышеупомянутой системе, в случае если TEE устройства контроллера A не запускает работу токена или останавливает работу токена до его передачи на устройство контроллера B:

- TEE устройства контроллера A может генерировать проверяемую подпись одноразового использования, доказывающую, что автономный токен был остановлен, а устройство контроллера A генерирует подпись притязания на владение одноразового использования, соответствующую новому притязанию на владение токеном для контроллера A;

- контроллер A может отправлять на сервер запрос на возврат, указывающий серверу вернуть токен в режим «онлайн» вместе с проверяемой подписью одноразового использования и подписью притязания на владение одноразового использования, посредством связи в режиме «онлайн» с помощью блока связи устройства контроллера A;

- после приема указанного запроса на возврат сервер может проверить действительность запроса, выполнив следующие операции:

верификации того, что токен действительно находится в автономном режиме, затем

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

[021] Согласно вышеупомянутой системе, в случае передачи в режиме «онлайн» токена, принадлежащего контроллеру А устройства, другому контроллеру B другого устройства, передачу можно осуществлять путем выполнения следующих операций:

- отправки контроллером A контроллеру B уникального идентификатора токена, подлежащего передаче, посредством автономной связи между блоками связи устройства контроллера A и устройства контроллера B,

- обратной отправки контроллером B подписи притязания на владение одноразового использования контроллера B посредством автономной связи между блоками связи устройства контроллера B и устройством контроллера A,

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

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

- после приема, посредством связи в режиме «онлайн» с помощью блока связи устройства контроллера A, и верификации ответа о владении от контроллера A сервер верифицирует действительность подписи владения одноразового использования контроллера B в запросе на передачу, и

в случае если указанная подпись владения одноразового использования является действительной, сервер заменяет притязание на владение токеном, соответствующее уникальному идентификатору токена, притязанием на владение токеном, соответствующим контроллеру B, и отправляет обратно подтверждение передачи контроллеру A посредством связи в режиме «онлайн» с помощью блока связи устройства контроллера A,

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

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

Краткое описание чертежей

На фиг. 1 схематически проиллюстрирована система, содержащая сервер (S) для контроля за операциями двух взаимосвязанных устройств D(A) и D(B).

На фиг. 2 схематически проиллюстрирован вариант осуществления передачи в режиме «онлайн» токена, принадлежащего контроллеру A устройства D(A), другому контроллеру B другого устройства D(B).

На фиг. 3 схематически проиллюстрированы основные операции «Выборка», «Обмен» и «Рассылка», выполняемые между сервером S и устройствами D(A) и D(B) контроллеров CA и CB для реализации автономной передачи токена между D(A) и D(B) согласно настоящему изобретению.

На фиг. 4 схематически проиллюстрирован вариант осуществления операции выборки токена контроллером СА устройства D(A) с сервера S для подготовки автономной передачи согласно настоящему изобретению токена Т, принадлежащего контроллеру СА, контроллеру CB устройства D(B).

На фиг. 5A схематически проиллюстрирован вариант осуществления операции автономной передачи OFFTRF согласно настоящему изобретению работающего токена RT, принадлежащего контроллеру CA устройства D(A), контроллеру CB устройства D(B).

Фиг. 5B является продолжением фиг. 5А.

На фиг. 6A схематически проиллюстрирован вариант осуществления операции остановки работающего токена RT и рассылки в режиме «онлайн» соответствующего запроса на передачу PUSONL устройством D(B) контроллера CB, получившим токен от контроллера CA устройства D(A) согласно настоящему изобретению.

Фиг. 6B является продолжением фиг. 6А.

Подробное описание

[023] Согласно варианту осуществления настоящего изобретения, схематически показанному на фиг. 1, сервер S контролирует операции, осуществляемые множеством устройств (в данном случае, показаны только два устройства: D(A) и D(B)), как, например, промышленные роботы в заводских или автоматизированных машинах на распределительной линии. Каждое устройство имеет блок обработки PU и блок связи CU. Каждое устройство управляется соответствующим контроллером (в данном случае, контроллер A, «CA», и контроллер B, «CB»). Сервер S обладает вычислительными возможностями и содержит модуль связи, чтобы обеспечить прямую передачу данных с помощью устройств, т. е. передачу данных в режиме «онлайн» через проводную или беспроводную сеть связи CN (например, Интернет), с использованием зашифрованного протокола связи и с использованием протокола верификации, включающего цифровые подписи владения одноразового использования и соответствующий протокол ZKP («доказательство с нулевым разглашением») действительности владения на основе притязания. Согласно настоящему изобретению защищенная передача данных включает обмен токенами. Сервер S может создавать цифровой токен T, содержащий соответствующий уникальный идентификатор токена Tid (например, серийный номер, возможно буквенно-цифровой), конкретные данные токена, назначенные сервером S и включающие цифровую подпись сервера SDS, и притязание на владение токеном Toc, соответствующее контроллеру, которому этот токен был приписан сервером S. Необязательно, подпись сервера SDS может быть добавлена к уникальному идентификатору токена вместо назначенных данных токена. Эти назначенные данные токена могут быть, например, запрограммированными командами, которые должны быть выполнены устройством контроллера, или приложением(-ями), которое(-ые) должно(-ы) быть запущено(-ы) на блоке обработки указанного устройства. Сервер S управляет базой данных DB, в которой хранятся токены. Первые две «записи» токена, т. е. уникальный идентификатор токена Tid и назначенные данные токена (с подписью сервера SDS), являются неизменяемыми, в то время как третья запись (т. е. притязание на владение токеном Toc) может быть изменена (согласно возможной передаче токена от контроллера другому контроллеру). Третья запись токена - это зашифрованный ключ владения или любая функция, данные или часть кода, позволяющая выполнить забывчивое притязание на владение, не раскрывая владельца. Сервер S хранит токены в базе данных DB и обновляет содержимое DB согласно различным передачам токенов между устройствами по линии связи. Согласно настоящему изобретению каждый контроллер может напрямую связываться с сервером S посредством передачи данных в режиме «онлайн» и протокола ZKP, чтобы знать токены, которыми он владеет, их соответствующие уникальные идентификаторы токенов и назначенные данные токенов.

[024] Операции, которые должны осуществляться устройством, в частности, в случае взаимодействия устройств для реализации сложных задач, включают передачу токенов между устройствами без участия сервера S, т. е. автономной передачи данных между этими устройствами. Автономные связи между устройствами (т. е. между их соответственными блоками связи) по каналу беспроводной связи CL (например, «Локальная сеть» LAN, такая как Wi-Fi, или «Личная сеть» PAN, такая как Bluetooth, «Ассоциация передачи данных в инфракрасном диапазоне» IrDA, беспроводной USB, или «Беспроводная связь ближнего радиуса действия» NFC) или по каналу проводной связи CL (например, LAN, такая как Ethernet), также используют протокол связи с цифровой подписью владения одноразового использования и притязанием на действительность подписи владения, т. е. «притязание на владение» для краткости, с верификациями на основе протокола ZKP. Блок обработки PU и блок связи CU каждого устройства защищенным образом подключены к соответствующим аппаратным средствам доверенной среды исполнения TEE. Каждая TEE устройства имеет память и защищенным образом подключена к блоку связи CU устройства посредством предназначенного пути защищенных аппаратных средств. Блоки связи CU устройств выполнены с возможностью взаимодействия друг с другом по протоколу доказательства с нулевым разглашением ZKP для проверки действительности (в автономном режиме) подписи (доказательства подписи) цифрового артефакта по линии связи CL в автономном режиме (т. е. без участия сервера S) для обмена токенами и доступа к их уникальным идентификаторам токенов и назначенным данным. После осуществления автономного обмена токенами между двумя контроллерами двух устройств согласно заданному протоколу автономного обмена (см. ниже), сервер S информируется о передачах на более поздней стадии, когда контроллер, принявший один или несколько токенов, связывается с сервером в режиме «онлайн» (с помощью блока связи своего устройства по сети связи CN) и передает список токенов, принятых в автономном режиме. Более того, сервер S может незаметно составить список уникальных идентификаторов токенов, которые были переданы в автономном режиме. И наоборот, каждый контроллер устройства может незаметно (т. е. не раскрывая свою личность) запросить у сервера S (посредством связи в режиме «онлайн» между блоком связи устройства и сервером) список токенов (с их назначенными данными), принадлежащих указанному контроллеру согласно (обновленному) содержимому в базе данных DB.

[025] Согласно настоящему изобретению передача токена между двумя контроллерами может быть реализована в режиме «онлайн» или в автономном режиме. На фиг. 2 представлена схема, на которой проиллюстрирован вариант осуществления случая передачи в режиме «онлайн» ONLTRF токена T, принадлежащего контроллеру CA устройства D(A), другому контроллеру CB другого устройства D(B). Такая передача включает следующие операции:

- контроллер CA отправляет контроллеру CB уникальный идентификатор токена Tid токена T (принадлежащего контроллеру CA), который контроллер CA хочет передать контроллеру CB, т. е. уникальный идентификатор токена Tid отправляется контроллером CA с помощью блока связи CU устройства D(A) блоку связи CU устройства D(B) по линии связи CL;

- после приема переданного Tid (блоком связи) контроллером CB, контроллер CB генерирует подпись притязания на владение одноразового использования GEN SUOCS(B) контроллера CB, а затем отправляет обратно в (блок связи устройства D(A)) контроллер CA сгенерированную подпись притязания на владение одноразового использования SUOCS(B) контроллера CB, с помощью блока связи CU устройства D(B) по CL;

- после приема подписи притязания на владение одноразового использования SOUCS(B) контроллера CB, контроллер CA отправляет запрос на передачу в режиме «онлайн» ONLTRF(A) на сервер S, содержащий уникальный идентификатор токена Tid и принятую подпись притязания на владение одноразового использования SUOCS( B) контроллера CB, т. е. запрос на передачу ONLTFR(A) отправляется блоком связи CU D(A) на сервер S по сети связи CN (см. подсхему «par» на фиг. 2);

- после приема указанного запроса на передачу ONLTRF(A) сервер S проверяет (см. подсхему «alt [пока OK]» на фиг. 2), действительно ли уникальный идентификатор токена Tid в запросе на передачу сохранен в базе данных DB с соответствующим притязанием на владение токеном Toc (обычно притязание на владение соответствует контроллеру CA), т. е. сервер S получает соответствующие Tid и Toc (см. операцию GET[Tid,Toc] на фиг. 2), а затем, в случае если токен хранится в DB, сервер S отправляет указанное притязание на владение токеном Toc контроллеру CA, т. е. сервер S отправляет Toc блоку связи CU устройства D(A) контроллера CA по сети связи CN;

- после приема Toc контроллер CA отправляет обратно на сервер S ответ о владении ANS(Toc) на принятое притязание на владение Toc, т. е. блок связи CU D(A) отправляет ответ о владении, вычисленный блоком обработки PU D(A), по сети связи CN;

- после приема ответа о владении от контроллера CA ANS(Toc) и верификации указанного ответа VER ANS(Toc) сервером S, сервер S верифицирует (см. операцию VER SUOCS(B)), что подпись владения одноразового использования SUOCS(B) контроллера CB в запросе на передачу ONTR(A) является действительной. В случае если указанная подпись владения одноразового использования SUOCS(B) является действительной, сервер S предоставляет притязание на владение токеном Toc’, соответствующее принятой подписи владения одноразового использования SUOCS(B) контроллера CB (см. операцию Toc’ = FUN[SUOCS(B)], указывая на то, что Toc’ зависит от SUOCS(B)) и заменяет притязание на владение токеном Toc, соответствующее уникальному идентификатору токена Tid, притязанием на владение токеном Toc’ в базе данных DB (см. операцию REP Toc’→ Toc) и отправляет обратно сообщение о «подтверждении передачи» CT (блоку связи CU устройства D(A)) контроллеру CA. В случае если указанная подпись владения одноразового использования SUOCS(B) является недействительной, сервер S отправляет обратно сообщение об «ошибке передачи» FT контроллеру CA по сети связи CN (см. подсхему «alt [НЕ OK]» на фиг. 2). Контроллер CB может проверить, была ли выполнена смена владения (т. е. передача токена от контроллера CA контроллеру B) посредством связи в режиме «онлайн» между блоком связи CU его устройства D(B) и сервером S, отправив запрос на владение (см. операцию QRYOWN[Tid] подсхемы «цикл [до истечения времени ожидания RES OR]» на фиг. 2), содержащий принятый уникальный идентификатор токена Tid токена T, на сервер S (с помощью блока связи CU устройства D(B)). После приема указанного запроса на владение сервер S получает из базы данных DB (обновленное) притязание на владение токеном, соответствующее принятому Tid (см. операцию GET[Tid,Toc]), и отправляет обратно в блок связи CU устройства B(B) контроллера CB полученное притязание на владение токеном Toc. После приема этого притязания на владение токеном Toc контроллер CB отправляет обратно на сервер S ответ о владении ANS(Toc) на принятое притязание на владение Toc, т. е. блок связи CU D(B) отправляет ответ о владении ANS(Toc), вычисленный блоком обработки PU D(B), по сети связи CN. После приема ответа о владении ANS(Toc) сервер S верифицирует принятый ответ (см. операцию RES = VER ANS(Toc)) и отправляет обратно на блок связи CU устройства D(B) контроллера CB указанный результат RES. В случае если указанный результат RES является положительным, это указывает контроллеру CB, что передача токена была выполнена (т. е. контроллер CB теперь является владельцем токена T, зарегистрированного в базе данных DB). На самом деле, устройство D(B) начинает проверку немедленно и опрашивает до тех пор, пока не будет получен положительный результат или не истечет время.

[026] На фиг. 3 схематически проиллюстрированы основные операции «Выборка», «Обмен» и «Рассылка», выполняемые между сервером S и устройствами D(A) и D(B) контроллеров CA и CB для реализации автономной передачи токена между устройствами D(A) и D(B) согласно настоящему изобретению.

[027] На фиг. 4 схематически проиллюстрирован вариант осуществления операции выборки (см. также операцию «Выборка» на фиг. 3) токена T контроллером СА устройства D(A) с сервера S для подготовки автономной передачи согласно настоящему изобретению токена Т, принадлежащего контроллеру СА, контроллеру CB устройства D(B). Такая выборка включает следующие операции:

- перед переходом в автономный режим контроллер CA устройства D(A) сначала осуществляет запрос на автономную передачу FETOFF(A), содержащий уникальный идентификатор токена Tid и (автономную) подпись TEE одноразового использования TEE-SUS(A) доверенной среды исполнения TEE D(A) устройства D(A). На практике блок связи CU устройства D(A) отправляет уникальный идентификатор токена Tid токена T своей TEE D(A), затем TEE D(A) генерирует подпись одноразового использования доверенной среды исполнения GEN TEE-SUS( A) и отправляет обратно в блок связи CU устройства D(A) сгенерированную TEE-SUS(A). Затем устройство D(A) отправляет на сервер S (посредством связи в режиме «онлайн» по сети связи CN) запрос на автономную передачу FETOFF(A)[Tid,TEE-SUS(A)], содержащий уникальный идентификатор токена Tid и подпись TEE одноразового использования TEE-SUS(A);

- после приема указанного запроса на автономную передачу FETOFF(A)[Tid,TEE-SUS(A)] (см. подсхему «alt [пока OK]» на фиг. 4) сервер S проверяет GET(Tid,Toc), что уникальный идентификатор токена Tid действительно находится в базе данных DB с соответствующим притязанием на владение токеном Toc, а затем отправляет указанное притязание на владение токеном контроллеру CA (т. е. S отправляет Toc на блок связи CU устройства D(A) контроллера CA по сети связи CN);

- блок связи CU устройства D(A) контроллера CA принимает от S притязание на владение токеном Toc, блок обработки PU устройства D(A) вычисляет соответствующий ответ о притязании на владение ANS(Toc) на принятый Toc, и блок связи CU устройства D(A) отправляет обратно на сервер S этот ответ о притязании на владение ANS(Toc);

- после приема ANS(Toc) и верификации VER ANS(Toc) ответа о притязании на владение от контроллера CA сервер S верифицирует VER TEE-SUS(A), что автономная подпись TEE одноразового использования TEE-SUS(A), принятая с соответствующим запросом на автономную передачу FETOFF(A)[Tid,TEE-SUS(A)], является действительной. В случае если указанная автономная подпись TEE одноразового использования TEE-SUS(A) является действительной, сервер S генерирует Toc’ = FUN[TEE-SUS(A)] притязание на владение токеном Toc’, соответствующее действительной автономной подписи TEE одноразового использования TEE-SUS(A), и заменяет притязание на владение токеном, соответствующее уникальному идентификатору токена Tid, притязанием на владение токеном Toc’, соответствующим автономной подписи TEE одноразового использования TEE-SUS(A), в базе данных DB (см. операцию REP Toc’→ Toc). Затем сервер S отправляет обратно в TEE D(A) устройства D(A) «рабочий токен» RT, и TEE устройства D(A) контроллера CA затем начинает выполнение токена RT (см. подсхему «цикл [до STOP] RUN RT», а сервер S далее отправляет обратно в блок связи CU устройства D(A) подтверждающее сообщение CM, указывающее, что токен RT работает в TEE D(A) и может быть передан.

В случае если указанная автономная подпись одноразового использования TEE-SUS(A) является недействительной, сервер S отправляет обратно соответствующее сообщение об ошибке FM, соответствующее недействительной автономной подписи одноразового использования TEE-SUS(A), в блок связи устройства D(A) контроллера CA по сети связи CN.

- в случае если контроллер CA принимает подтверждающее сообщение CM, относящееся к работоспособному токену RT, и TEE D(A) начала выполнение (работу) указанного токена RT (см. фиг. 5A), блок связи CU устройства D(A) контроллера CA раскрывает EXP RT работающий токен RT блоку связи CU устройства D(B) контроллера CB, который затем непрерывно наблюдает OBS RT за работающим токеном RT, синхронизируется с ним в своей доверенной среде исполнения TEE D(B). В предпочтительном режиме доверенная среда исполнения TEE D(A) устройства D(A) раскрывает работающий токен RT с помощью «периферийного устройства для экстернализации» (EP), D(A) TEE EP, для передачи работающего маркера RT по (автономному) каналу связи CL (см. подсхему «цикл [до END]» на фиг. 5А). Периферийным устройством для экстернализации может быть, например, выходной канал периферийного устройства связи PAN/LAN, как, например, Wi-Fi, Bluetooth, IrDA, беспроводной USB или NFC, который должен быть сопряжен на стороне устройства D(B) с их соответствующим входным каналом в качестве «периферийного устройства для интернализации», а также дисплей/экран, который должен быть сопряжен с камерой в качестве устройства для интернализации для формирования системы связи экран-камера. Как упоминалось выше, устройство D(B) затем может непрерывно наблюдать (см. подсхемы «цикл [до CHGTRG]]» и «цикл [до истечения времени ожидания CHGOWN OR]» на фиг. 5A) за раскрытым работающим токеном RT в доверенной среде исполнения TEE D(B). Предпочтительно, операции наблюдения за RT (по линии связи CL) и синхронизация с работающим токеном RT осуществляют с помощью «периферийного устройства для интернализации» (IP), TEE D(B) IP устройства D(B). Затем доверенная среда исполнения TEE D(B) получает работающий токен RT от TEE D(B) IP и проверяет «VER S», подписан ли (i) работающий токен RT сервером S, и проверяет «VER OWN(A)», является ли (ii) владельцем работающего токена RT действительно контроллер CA (см. подсхему «цикл [до CHGTRG]» на фиг. 5A). Предпочтительно, более позднюю операцию осуществляют с помощью протокола верификации доказательства с нулевым разглашением ZKP (см. подсхему VER OWN(A) на фиг. 5A): блок связи CU устройства D(B) отправляет (в автономном режиме по линии связи CL) притязание владельца ZKP ZKPOWN на блок связи устройства D(A), блок связи устройства D(A) отправляет обратно соответствующий ответ о притязании на владение ANS(ZKPOWN) блоку связи CU устройства D(B) и доверенной среде исполнения TEE D(B) устройства D(B), затем верифицирует VER ANS(ZKPOWN) принятый ответ. Кроме того, доверенная среда исполнения TEE D(B) устройства D(B) верифицирует (iii), что наблюдаемый токен RT действительно работает в доверенной среде исполнения устройства контроллера CA, VER RUN(RT). Эту более позднюю операцию осуществляют с помощью протокола верификации доказательства с нулевым разглашением ZKP (см. подсхему VER RUN(RT) на фиг. 5A): блок связи CU устройства D(B) отправляет (в автономном режиме по линии связи CL) работающее притязание ZKP ZKPRUN на блок связи CU устройства D(A), блок связи CU устройства D(A) отправляет обратно соответствующий ответ о работающем притязании ANS(ZKPRUN) блоку связи CU устройства D(B) и доверенной среде исполнения TEE D(B) устройства D(B), затем верифицирует VER ANS(ZKPRUN) принятый ответ.

- затем, в случае выполнения вышеупомянутых условий (i)-(iii), устройство D(B) отправляет сообщение RTCHK по линии связи CL, чтобы сообщить устройству D(A), что работающий токен действительно подписан S, принадлежит контроллеру CA и работает. В случае невыполнения всех этих условий, устройство D(B) отправляет соответствующее сообщение NOT RTCHK по линии связи CL.

- При этом, после приема сообщения RTCHK устройством D(A) (см. подсхему «цикл [до RTCHK]» на фиг. 5B), контроллер CA начинает менять владение работающего токена RT в пользу контроллера CB, отправив сообщение CHGOWN(B) в TEE D(A) с помощью блока связи CU устройства D(A). Эту операцию предпочтительно осуществляют с помощью протокола верификации подписи доказательства с нулевым разглашением ZKP (см. подсхему «CHGOWN(B)» на фиг. 5B): D(A) отправляет притязание ZKPSIG подписи ZKP на D(B), затем D(B) отправляет обратно D(A) ответ о притязании ANS(ZKPSIG), после верификации принятого ответа устройство D(A) изменяет владение токеном, работающим в его TEE, в пользу контроллера CB на основе принятого ответа CHGOWN[ANS(ZKPSIG)], и соответствующее сообщение CHGTRG отправляется D(A) по линии связи CL, чтобы сообщить контроллеру CB об изменении владения работающим токеном RT (в пользу CB). Теперь в интересах D(A) остановить работу токена STOP RT в его TEE D(A) (например, чтобы уменьшить потребление энергии D(A)), см. подсхему «цикл [до CHGOWN]» на фиг. 5B. После остановки работающего токена RT в TEE D(A) устройства D(A), TEE D(A) отправляет сообщение CT о подтверждении передачи на устройство D(A).

- Между тем, после приема сообщения CHGTRG устройством D(B), по линии связи CL (см. подсхему «цикл [до истечения времени ожидания CHGOWN OR]» фиг. 5A) доверенная среда исполнения TEE D(B) устройства D(B) получает работающий токен RT из наблюдаемого работающего токена OBS RT, верифицирует VER S, что токен подписан сервером S, и проверяет VER OWN(B), является ли (новый) владелец работающего токена RT контроллером CB и действительно ли VER RUN(RT) работает токен. Эту более позднюю операцию предпочтительно осуществляют с помощью протокола верификации доказательства с нулевым разглашением ZKP (см. подсхему «VER RUN(RT)» на фиг. 5A): D(B) отправляет притязание ZKP ZKPRUN в D(A), затем D(A) отправляет обратно в D(B) ответ о притязании ANS(ZKRUN), после верификации принятого ответа устройство D(B) отправляет сообщение CHGOWN по линии связи, чтобы сообщить контроллеру CA, что владельцем работающего токена теперь является контроллер CB. В случае если верификация того, что токен работает, дает отрицательный результат, устройство D(B) отправляет сообщение NOT CHGOWN по линии связи, чтобы сообщить контроллеру A, что смена владельца не была выполнена.

- после смены владения TEE устройства контроллера B также имеет преимущество, чтобы остановить работу токена T (см. фиг. 6A) и сгенерировать доказательство остановки, а затем контроллер B рассылает в режиме «онлайн» запрос на передачу PUSONL(B), содержащий уникальный идентификатор токена Tid, доказательство остановки COTS(B) и сгенерированную подпись притязания на владение одноразового использования SUOCS(B) в сервер S;

- при приеме указанного запроса на передачу PUSONL(B) сервер S проверяет действительность запроса, и, в случае если запрос является действительным, он осуществляет соответствующее изменение притязания на владение токеном для этого токена T (т. е. токена, имеющего уникальный идентификатор токена Tid) в базе данных DB.

[028] На фиг. 6A-B проиллюстрирован вариант осуществления операций остановки работающего токена RT и рассылки в режиме «онлайн» соответствующего запроса на передачу PUSONL устройством D(B) контроллера CB, получившим токен от контроллера CA устройства D(A) согласно настоящему изобретению. При остановке STOP RT для работы автономного токена RT посредством TEE устройства D(B) контроллера CB:

- TEE устройства D(B) контроллера CB генерирует GEN COTS(B)[RT] проверяемую подпись одноразового использования COTS(B)[RT], подтверждающую, что автономный токен RT остановлен, устройство D(B) генерирует GEN SUOCS(B) подпись владения одноразового использования SUOCS(B), доказывающую, что контроллер B является владельцем работающего токена, а устройство D(B) рассылает в режиме «онлайн» в сервер S запрос на передачу PUSONL(B)[Tid,COTS(B),SUOCS(B)], содержащий уникальный идентификатор токена Tid (остановленного) токена, проверяемую подпись одноразового использования COTS(B) и подпись владения одноразового использования SUOCS(B);

- после приема указанного запроса на передачу PUSONL(B) сервер S проверяет действительность запроса на передачу PUSONL(B), выполнив следующие этапы (см. подсхему «alt [пока OK]» на фиг. 6A):

а) проверки того, что токен, имеющий принятый уникальный идентификатор токена Tid, действительно находится в автономном режиме. Сервер S получает из базы данных GET[Tid,Toc] притязание на владение токеном Toc, соответствующее Tid. Затем сервер S проверяет VER OFFLIN Toc, что соответствующий токен действительно находится в автономном режиме.

b) верификации действительности принятой проверяемой подписи одноразового использования COTS(B), а затем, в случае если она является действительной, оспаривания права владения токеном Tid путем отправки в режиме «онлайн» полученного притязания на владение токеном Toc на устройство D(B). После приема притязания на владение токеном Toc устройство D(B) отправляет обратно соответствующий ответ ANS(Toc) на сервер S, и сервер S верифицирует VER ANS(Toc) принятый ответ о притязании на владение токеном Toc и принятую проверяемую подпись одноразового использования VER COTS(B). В случае если и ANS(Toc), и COTS(B) являются действительными, сервер S генерирует Toc’ = FUN[SUOCS(B)] новое притязание на владение токеном Toc’ в зависимости от принятой подписи владения одноразового использования SUOCS(B) для контроллера CB, и заменяет REP Toc’→ Toc в базе данных DB притязание на владение токеном Toc новым притязанием на владение токеном Toc’, указывающим, что новым владельцем токена, соответствующего Tid, является контроллер CB, и отправляет соответствующее подтверждающее сообщение CM на устройство D(B).

[029] Контроллер CB устройства D(B) может проверить, действительно ли сервер S изменил право владения на переданный токен, имеющий уникальный идентификатор токена Tid (см. подсхему «цикл [до истечения времени ожидания RES OR]» на фиг. 6A), отправив соответствующий запрос на владение QRYOWN[Tid].

[030] Преимущество вышеупомянутой автономной передачи согласно настоящему изобретению состоит в том, что, в случае если притязание на владение токеном Toc работающего токена RT было изменено на притязание на владение токеном Toc’ в пользу контроллера CB, как у контроллера CA, так и у контроллера CB есть копия работающего токена RT в их соответственной TEE, но только контроллер CB может подтвердить право владения. Таким образом, работающий токен RT не может быть далее использован (или передан) контроллером CA и может использоваться только контроллером CB для управления операциями, соответствующими назначенным данным токена (выполняемым с помощью устройства D(B)).

[031] Еще одно преимущество вышеупомянутой автономной передачи согласно настоящему изобретению состоит в том, что контроллер CA после изменения владения токеном в пользу контроллера B заинтересован в остановке (копии) работающего токена и удалении его для того, чтобы сэкономить энергию (например, батареи) устройства D(A).

[032] В предпочтительном режиме TEE устройства D(B) контроллера B выполняет вышеупомянутую операцию проверки (ii) того, что токен T принадлежит контроллеру CA, посредством протокола доказательства с нулевым разглашением ZKP на устройстве D(B) контроллера CB при автономной связи (т. е. посредством связи по локальной линии связи CL) с TEE устройства D(A) контроллера CA. Таким образом, только контроллеры CA и CB устройств D(A) и D(B) знают, что идет передача токена T, а сервер S знает только, что токен T работает в автономном режиме.

[033] Кроме того, в предпочтительном режиме TEE устройства D(B) контроллера B осуществляет вышеупомянутую операцию проверки (iii) того, что токен T действительно работает в доверенной среде исполнения TEE устройства D(A) контроллера А посредством динамической синхронизации/реконструкции состояния систем (см. [12], [13]) и доказательства с нулевым разглашением ZKP для подписи TEE на устройстве D(B) контроллера B в автономном режиме связи с помощью блока связи устройства D(A) контроллера A.

[034] Цель доказательства работы состоит в том, чтобы избежать некоторых простых мошенничеств/атак, которые обеспечили бы возможность «двойного использования» токена, а именно копирование и повторное воспроизведение:

• Копирование: динамический токен предотвращает двойное использование, предотвращая действительность простой статической копии, которую можно получить, например, при раскрытии токена для использования устройству B; т. е. контроллером A, выдающим себя за контроллер B, чтобы получить вторую копию токена на контроллере A.

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

Следовательно, доказательство работы должно удовлетворять следующим требованиям:

• как всегда в криптографии, криптографические вычисления доказательства работы должны быть сложными для вычисления/подделки, но достаточно простыми для верификации;

• должны быть верифицируемыми (вычислительная сложность) в основном в пределах временного интервала его действия;

• временной интервал его действия должен быть сравним со временем выполнения автономной передачи (например, от секунд до десятков секунд), чтобы предотвратить многократное параллельное/последовательное использование (вариант повторной атаки);

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

• метод должен предотвращать атаки быстрой перемотки вперед и повторного воспроизведения.

Известные решения, отвечающие требованиям, очень похожим на раскрытые в данном документе, встречаются (под другими названиями) в некоторых других случаях использования, например:

- Продажа билетов на общественный транспорт без шлагбаума на основе мобильного телефона (см. [14], [15], [16]), где были предложены различные решения, чтобы доказать, что доверенное приложение для продажи билетов/подсчета (TA, см. [17]) никогда не останавливалось в пути, даже при работе в автономном режиме; большинство решений полагаются на выделенные постоянно увеличивающиеся регистры в TEE;

- Доказательство прошедшего времени в разрешенных протоколах консенсуса блокчейна (см. [18][19][20]), где было предложено решение, использующее доверенную среду исполнения Intel (SGX), чтобы гарантировать две вещи: 1) что участвующие узлы действительно выбирают время, которое действительно является случайным, а не короче, намеренно выбранным участниками для победы, и 2) победитель действительно завершил время ожидания; последнее здесь представляет интерес.

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

а) постоянно увеличивающийся регистр TEE + подпись TEE: этот конкретный вариант осуществления полностью аналогичен некоторым решениям, используемым в продаже билетов на общественный транспорт без шлагбаума. В этом простом случае TEE предоставляет регистр обнаружения несанкционированного доступа, который постоянно увеличивается с течением времени с фиксированной скоростью; когда токен выбирается в автономном режиме, TEE D(A) принимает и сохраняет подписанную (сервером S) временную метку времени выборки и запускает счетчик (регистр). Во время проверки действительности TEE D(A) раскрывает временную метку сервера и подписанное значение TEE регистра; TEE D(B) проверяет временную метку сервера с помощью открытого ключа сервера и регистр с помощью открытого ключа TEE, затем проверяет, что значение счетчика/регистра совместимо с текущим временем и временем выборки: т. е.

currentTime=fetchTime+countervalue*DT (с допустимым отклонением), где DT - время выборки, при котором регистр обновляется; следовательно, доказывая, что доверенное приложение токена в TEE никогда не останавливалось.

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

b) Нетривиальная динамическая система + доказательство прошедшего времени от TEE: этот конкретный вариант осуществления использует механизмы доказательства прошедшего времени, уже доступные в данной области техники, чтобы предотвратить атаку с быстрой пересылкой и повторным воспроизведением и, в то же время, обеспечивает быструю проверку действительности нетривиальной итерационной динамической системы. В этом случае доказательство работы состоит из двух частей: начального (X(0)) и текущего состояния (X(n)) нетривиальных динамических систем (например, хаотического или псевдослучайного генератора вида X(n +1)=F(X(n),P), где X(n) - состояние на итерации n, а P - вектор параметров управления, а также доказательство того, что TEE выполняла итерацию в правильном темпе, т. е. каждый этап от n до n+1 был отделен фиксированным количеством времени DT. При выборке токена в автономном режиме, TEE D(A) принимает и сохраняет (подписано сервером S): 1) временную метку времени выборки, как и для предыдущей реализации; 2) набор параметров управления P, определяющих настройки нетривиальной динамической системы (параметры бифуркации); 3) начальное состояние X(0) динамической системы. TEE использует открытый ключ сервера S для верификации подписи сервером и немедленно начинает повторять динамическую систему, обновляя свое состояние (X(n+1)=F(X(n),P)) с фиксированной скоростью DT; наряду с этим, для каждого этапа обновления TEE генерирует доказательство прошедшего времени DT перед выполнением обновления состояния и присоединяется к нему (оператор AND) в рамках общего доказательства прошедшего времени; доказательство прошедшего времени состоит из количества выполненных этапов итерации и общего количества прошедшего времени, оба из которых подписаны TEE. Во время проверки действительности TEE D(A) раскрывает: временную метку сервера, параметр P и начальное состояние X(0) (все подписано сервером); и текущее состояние X(n), количество итераций n и общее прошедшее время elapsedTime (все подписано TEE). TEE D(B) верифицирует информацию о сервере с помощью открытого ключа сервера и информацию TEE с помощью открытого ключа TEE, а затем верифицирует, что значение доказанного прошедшего времени совместимо с текущим временем и временем выборки (как в предыдущем варианте осуществления currentTime=fetchTime+elapsedTime с допустимым отклонением); наконец, она быстро итерирует динамическую систему n раз от X (0) до X (n), используя параметр P, и верифицирует, что она получает то же самое текущее состояние, которое заявлено TEE; следовательно, окончательное доказательство того, что доверенное приложение токена в TEE выполнялось, как ожидалось, и никогда не было остановлено.

Эта последняя реализация немного сложнее, чем предыдущий вариант осуществления, она по-прежнему требует умеренно низких вычислительных затрат (все еще выше, чем в предыдущем случае) как для сторон генерации, так и для проверки действительности, с другой стороны, тем не менее, она немного снижает корень доверия к аппаратным средствам TEE (которые по-прежнему являются единственным корнем доверия в течение прошедшего времени), добавив дополнительную перекрестную проверку итерированной нетривиальной динамической системы, которая связывает корень доверия с сервером (верифицируемая принятая временная метка, X(0) и P) и целостности TEE (которая все время правильно вычисляла X(n+1)=F(X(n),P)).

c) Облегченный токен на основе блокчейна: этот конкретный вариант осуществления является дальнейшим развитием предыдущего, направленным на еще большее снижение эксклюзивности корня доверия в аппаратных средствах TEE. Для этой реализации ингредиенты в основном такие же, как и для предыдущей, где вместо кумулятивного доказательства затраченного времени и количества этапов итерации TEE должна создавать (достаточно сложное для вычисления) доказательство каждой выполненной итерации в форме блокчейна, основанной на информации, принятой от сервера S во время выборки в автономном режиме, и с блоком для каждого этапа итерации. Еще раз, при выборке токена в автономном режиме, TEE D(A) принимает и сохраняет (подписано сервером): 1) временную метку времени выборки; 2) набор параметров управления P, определяющих настройки нетривиальной динамической системы; 3) начальное состояние X(0) динамической системы. TEE использует открытый ключ сервера для верификации подписи сервером и: сначала создает корневой узел доказательства или работающего блокчейна с информацией, принятой от сервера, затем сразу же начинает итерацию динамической системы, обновляя свое состояние (X(n+1)=F(X(n),P)) и добавляя один блок в блокчейн для каждого этапа итерации. Каждый блок содержит ссылку на предыдущий блок через хэш-значение предыдущего блока, состояние динамической системы X(n), текущую временную метку и случайное число для решения относительно простой криптографической головоломки, чтобы иметь доказательство работы, наконец, блок подписан TEE. Комбинация доказательства работы и подписи TEE предотвращает ускоренное вычисление внутри или вне TEE. Во время проверки действительности TEE D(A) раскрывает весь блокчейн, вычисленный до этого момента, а TEE D(B) после проверки действительности подписей (сервер S и TEE) проверяет доказательство работы, проверяя действительность всего блокчейна с помощью стандартных методов проверки действительности блокчейна; следовательно, доказывая, что доверенное приложение токена в TEE выполнялось, как ожидалось, и никогда не останавливалось.

Эта реализация в значительной степени снижает корень доверия к аппаратной целостности TEE за счет гораздо большей вычислительной сложности как во время генерации, так и во время проверки действительности, а также с точки зрения вычислительной мощности и памяти. С одной стороны, криптографическая головоломка, даже если она проста для совместимости с вычислительной мощностью TEE, все равно должна быть решена в течение выделенного промежутка времени. С другой стороны, доказательство токена растет линейно во времени. Предполагая, что блок размером приблизительно 75 байтов (16 байтов хэша, 4x8 байтов состояния, 8 байтов временной метки, 2-3 байта случайного числа, 16 байтов подписи) и частотой дискретизации приблизительно 10 секунд за одну неделю (что является разумным максимальным интервалом, чтобы держать токен в автономном режиме), доказательство работы вырастет приблизительно до 4 Мбайт, разумного, но все же заметного размера, особенно с учетом того, что это верно для каждого автономного токена.

[035] Согласно настоящему изобретению ниже описан альтернативный вариант осуществления, относящийся к доказательству работы без реконструкции, в котором требуется, чтобы можно было внутренне принудительно и внешне проверить, что токен работает, и он делает это в TEE. Для этого внутреннее текущее состояние доверенного приложения (ТА), в котором работает токен, должно быть раскрыто от контроллера CA устройства TEE D(A) к контроллеру CB устройства D(B), чтобы TEE D(B) мог верифицировать согласованность раскрытого состояния с гипотезой о том, что токен «работает» с тех пор, как он был выбран в автономном режиме, т. е. проверить действительность доказательства или работы. В зависимости от выбранного варианта доказательства работы, раскрытие и наблюдение за «работающим» состоянием может быть реализовано двумя возможными способами:

1. Косвенно раскрывая динамически изменяющееся состояние и прибегая к методам реконструкции динамических систем для полной реконструкции (синхронизации) внутреннего состояния (см. [12] [13]); или

2. Непосредственно раскрывая динамически изменяющееся состояние и, следовательно, наблюдая за ним непосредственно по выделенному каналу, такому как NFC, BT, BTLE или связь между дисплеем и камерой.

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

Второй случай представляет интерес в случае, когда работающая динамическая система за автономным токеном и выдача ее доказательства работы являются синхронными, в этом случае вся информация, необходимая для проверки действительности доказательства работы, явно раскрывается (передается) от устройства D(A) к устройству D(B) по выбранному каналу. Например, предположение о том, что каждые 10 секунд (весьма разумный темп) должно создаваться новое доказательство работы, и что время передачи данных и вычислений должно быть справедливо разделено, приведет к следующим максимальным размерам обмена данными:

• NFC: ~256 Кбайт

• BTLE: ~640 Кбайт

• BT: 1,2 Мбайт

• От экрана к камере (камера Full HD 20 кадров в секунду): ~3 Мбайт

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

[036] Согласно примеру реализации настоящего изобретения состояние изменения работающего токена можно защищенным образом (т. е. без возможности злонамеренного вмешательства третьей стороны или даже контроллера A) раскрыть через соединение от TEE устройства D(A) контроллера A к периферийному устройству для экстернализации (см. выше). Точно так же состояние можно защищенным образом наблюдать (от раскрытия) с помощью TEE устройства D(B) контроллера B (т. е. без возможности злонамеренного вмешательства третьей стороны или даже контроллера B). Эта конкретная реализация способа передачи с нулевым разглашением обеспечивает максимальную безопасность в отношении любой попытки вторжения.

[037] Предпочтительно, в вышеупомянутой автономной передаче согласно настоящему изобретению контроллер A изменяет притязание на владение токеном для работающего токена в пользу контроллера B посредством забывчивых вычислений на устройстве D(A) контроллера A в автономном режиме связи с помощью блока связи устройства D(B) контроллера B.

[038] На фиг. 6B, на подсхеме «[T@ A]», проиллюстрирован случай вышеупомянутой автономной передачи, когда TEE устройства D(A) контроллера CA не удалось запустить автономный токен с уникальным идентификатором токена Tid, либо досрочно остановила работу автономного токена (до его передачи в контроллер CB). В этом случае:

- устройство D(A) указывает STOP RT своей TEE, чтобы остановить работу токена RT, а блок обработки PU TEE D(A) генерирует GEN COTS(A)[RT] проверяемую подпись одноразового использования COTS(A), доказывающую, что автономный токен RT был остановлен, и блок обработки PU устройства D(A) контроллера CA генерирует GEN SUOCS(A) подпись владения одноразового использования SUOCS(A), соответствующую притязанию на владение токеном, для контроллера CA;

- контроллер А отправляет на сервер S с помощью блока связи устройства D(A) по сети связи CN запрос PUSONL(A)[Tid,COTS(A),SUOCS(A)], указывающий серверу S вернуть в режиме «онлайн» автономный токен T, имеющий уникальный идентификатор токена Tid, вместе с проверяемой подписью одноразового использования COTS(A) и подписью владения одноразового использования SUOCS(A);

- после приема указанного запроса на возврат PUSONL(A) сервер S проверяет действительность запроса PUSONL(A), выполнив следующие этапы:

1) сервер S получает GET[Tid,Toc] притязание на владение токеном Toc токена (см. подсхему «alt [пока успешно]» на фиг. 6B), имеющего уникальный идентификатор токена Tid, из базы данных DB, и верифицирует VER OFFLIN Toc, что токен действительно находится в автономном режиме, затем

2) сервер S отправляет полученное притязание Toc на устройство D(A) и верифицирует VER ANS(Toc), COTS(A)[RT] ответ ANS(Toc), отправленный обратно устройством D(A), и проверяемую подпись одноразового использования COTS(A), в случае если они являются действительными, сервер генерирует Toc’ = Fun[SUOCS(A)] притязание на владение Toc’ для контроллера CA на основе принятой подписи владения одноразового использования SUOCS(A), заменяет в базе данных DB сохраненное притязание на владение токеном Toc для этого уникального идентификатора токена Tid новым притязанием на владение токеном Toc’ и отправляет соответствующее подтверждающее сообщение CM на устройство D(A). Контроллер CA устройства D(A) может проверить (см. подсхему «цикл [до истечения времени ожидания RES OR]» на фиг. 6B), действительно ли он владеет автономным токеном уникального идентификатора токена Tid, отправив с помощью блока связи D(A) запрос на владение QRYOWN[Tid] на сервер S. В ответ на запрос сервер S получает GET[Tid,Toc] соответствующий Toc в DB и отправляет обратно притязание на владение токеном Toc на D(A), верифицирует RES = VER ANS(Toc) ответ ANS(Toc) D(A) на это притязание на владение и отправляет обратно D(A) результат RES этой верификации.

Если какая-либо из вышеупомянутых верификаций терпит неудачу, сервер S отправляет соответствующее сообщение об ошибке FM на устройство D(A).

[039] Согласно еще одному аспекту вышеописанное настоящее изобретение обеспечивает защищенный обмен токеном между двумя устройствами на основе комбинации работающего (цифрового) токена (который делает любую статическую или предыдущую копию токена бесполезной) вместе с кросс-функциями проверки устройств, могут также использоваться в контексте онлайн/оффлайн (т. е. вкл/выкл интернет) обмена токенами цифровой ценности (представляющими сумму денег) между двумя сторонами CA и CB. В этом случае контроллер может соответствовать владельцу токена цифровой ценности (например, физическому лицу или компании), устройства D(A) и D(B) могут соответствовать соответственным мобильным устройствам (например, смартфонам, планшетам и т. д.) владельцев CA и CB и сервер S может соответствовать уполномоченному органу (например, центральному банку), отчеканившему токен цифровой ценности. В этом случае данные токена, назначенные сервером, могут соответствовать простой номинальной стоимости (сумме денег) токена вместе с цифровой подписью уполномоченного органа (в качестве доказательства монетного двора).

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

[041] БИБЛИОГРАФИЧЕСКИЕ ССЫЛКИ

[1] M. Sabt, M. Achemlal, A. Bouabdallah: “Trusted Execution Environment: Wat It is, and What It is Not”, 14^ая IEEE International Conference on Trust, Security and Privacy in Computing and Communications, август 2015 г., Хельсинки, Финляндия.

[2] https://en.wikipedia.org/wiki/Trusted_execution_environment (ред. от 15 ноября 2020 г., в 13:04 (UTC)).

[3] из Crypto Wiki: cryptowiki.net/index.php?title=Protocols_for_secure_communication_channels (27 декабря 2014 г., в 21:54).

[4] S. Goldwasser, M. Bellare: “Lecture Notes on Cryptography”, июль 2008 г.: http://www.cs.tufts.edu/comp/165/papers/Goldwasser-Bellare-notes-cryptography.pdf

[5] https://en.wikipedia.org/wiki/Digital_signature (ред. от 14 декабря 2020 г., в 00:29 (UTC)).

[6] https://en.wikipedia.org/wiki/Blind_signature (ред. от 4 января 2020 г., в 18:21 (UTC)).

[7] D. Chaum, EUROCRYPT '90: Proceedings of the workshop on the theory and application of cryptographic techniques on Advances in cryptology, февраль 1991 г., страницы 458–464.

[8] Wikipedia. "Signatures with efficient protocols",

https://en.wikipedia.org/wiki/Signatures_with_efficient_protocols (ред. от 14 декабря 2020 г., в 02:13 (UTC)).

[9] Goldwasser S., Ostrovsky R. (1993) Invariant Signatures and Non-Interactive Zero-Knowledge Proofs are Equivalent. In: Brickell E.F. (eds) Advances in Cryptology - CRYPTO’ 92. CRYPTO 1992. Lecture Notes in Computer Science, вып. 740. Springer, Берлин, Гейдельберг. https://doi.org/10.1007/3-540-48071-4_16.

[10] Camenisch J., Lysyanskaya A. (2003) A Signature Scheme with Efficient Protocols. In: Cimato S., Persiano G., Galdi C. (eds) Security in Communication Networks. SCN 2002. Lecture Notes in Computer Science, вып. 2576. Springer, Берлин, Гейдельберг. https://doi.org/10.1007/3-540-36413-7_20.

[11] Knox, D.A. and Adams, C. "Digital credentials with privacy-preserving delegation", первая публикация: 15 июля 2011 г., https://doi.org/10.1002/sec.213,

(см. https://onlinelibrary.wiley.com/doi/full/10.1002/sec.213).

[12] https://en.wikipedia.org/wiki/State_observer (ред. от 12 ноября 2020 г., в 07:16 (UTC)).

[13] Kevin McGoff, Sayan Mukherjee, Natesh S. Pillai: "Statistical Inference for Dynamical Systems: A review". 2012 г. https://arxiv.org/pdf/1204.6265.pdf

[14] Ekberg, Jan-Erik & Kostiainen, Kari & Asokan, N. (2014): “The Untapped Potential of Trusted Execution Environments on Mobile Devices”, Security & Privacy, IEEE. 12. 29-37. 10.1109/MSP.2014.38.

[15] Ekberg JE., Tamrakar S. (2012): “Mass Transit Ticketing with NFC Mobile Phones”. In: Chen L., Yung M., Zhu L. (eds) “Trusted Systems”. INTRUST 2011. Lecture Notes in Computer Science, вып. 7222. Springer, Берлин, Гейдельберг.

[16] Tamrakar S., Ekberg JE. (2013): “Tapping and Tripping with NFC”. In: Huth M., Asokan N., Čapkun S., Flechais I., Coles-Kemp L. (eds) “Trust and Trustworthy Computing”. Trust 2013. Lecture Notes in Computer Science, вып. 7904. Springer, Берлин, Гейдельберг.

[17] “TEE System Architecture v1.2” | GPD_SPE_009 опубл. в декабре 2018 г. https://globalplatform.org/specs-library/tee-system-architecture-v1-2/

[18] Sawtooth v1.0.5 documentation: PoET 1.0 Specification,

https://sawtooth.hyperledger.org/docs/core/releases/1.0/architecture/poet.html

[19] Medium: Understanding Hyperledger Sawtooth - Proof of Elapsed Time. 20 февраля 2018 г.

https://medium.com/kokster/understanding-hyperledger-sawtooth-proof-of-elapsed-time-e0c303577ec1

[20] G. Prisco. Intel Develops ‘Sawtooth Lake’ Distributed Ledger Technology For The Hyperledger Project. Bitcoin Magazine, 11 апреля 2016 г.

https://bitcoinmagazine.com/articles/intel-develops-sawtooth-lake-distributed-ledger-technology-for-the-hyperledger-project-1460397461

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

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

причем способ отличается тем, что:

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

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

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

(i) токен подписан сервером,

(ii) владельцем токена является контроллер A, и

(iii) токен работает в доверенной среде исполнения устройства контроллера A;

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

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

2. Способ по п. 1, отличающийся тем, что на этапе (ii) TEE устройства контроллера B проверяет, что владельцем токена является контроллер A посредством протокола доказательства с нулевым разглашением ZKP на устройстве контроллера B в автономном режиме связи с помощью блока связи устройства контроллера А.

3. Способ по любому из пп. 1 и 2, отличающийся тем, что на этапе (iii) TEE устройства контроллера B проверяет, что токен работает в доверенной среде исполнения устройства контроллера A посредством динамической синхронизации/реконструкции состояния систем и протокола ZKP для подписи TEE на устройстве контроллера B в автономном режиме связи с помощью блока связи устройства контроллера A.

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

5. Способ по любому из пп. 1–4, отличающийся тем, что при остановке работы автономного токена посредством TEE устройства контроллера B,

TEE устройства контроллера B генерирует проверяемую подпись одноразового использования, доказывающую, что автономный токен был остановлен, и содержащую доказуемую проверку оригинальной автономной подписи TEE одноразового использования, и устройство контроллера B генерирует подпись притязания на владение одноразового использования;

контроллер B добавляет в запрос на передачу проверяемую подпись одноразового использования, доказуемую проверку оригинальной автономной подписи TEE одноразового использования и подпись притязания на владение одноразового использования, а также рассылает запрос на передачу в режиме онлайн на сервер; и

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

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

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

6. Способ по любому из пп. 1–3, отличающийся тем, что в случае если TEE устройства контроллера A не запускает работу токена или останавливает работу токена до его передачи на устройство контроллера B,

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

контроллер A отправляет на сервер запрос на возврат, указывающий серверу вернуть токен в режим онлайн вместе с проверяемой подписью одноразового использования и подписью притязания на владение одноразового использования;

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

верификации того, что токен действительно находится в автономном режиме, затем

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

7. Способ по любому из пп. 1–6, отличающийся тем, что в случае передачи в режиме онлайн токена, принадлежащего контроллеру А устройства, другому контроллеру B другого устройства, передача включает отправку контроллером A контроллеру B уникального идентификатора токена, подлежащего передаче, с помощью блока связи устройства, обратную отправку контроллером B подписи притязания на владение одноразового использования контроллера B с помощью блока связи другого устройства, отправку контроллером A запроса на передачу на сервер с указанием уникального идентификатора токена и принятой подписи притязания на владение одноразового использования контроллера B, после приема указанного запроса на передачу сервер проверяет, что уникальный идентификатор токена хранится в базе данных с соответствующим притязанием на владение токеном, а затем отправляет указанное притязание на владение токеном контроллеру А, после приема и верификации ответа о владении от контроллера A сервер верифицирует действительность подписи владения одноразового использования контроллера B в запросе на передачу, в случае если указанная подпись владения одноразового использования является действительной, сервер заменяет притязание на владение токеном, соответствующее уникальному идентификатору токена, притязанием на владение токеном, соответствующим контроллеру B, и отправляет обратно подтверждение передачи контроллеру A, в случае если указанная подпись владения одноразового использования является недействительной, сервер отправляет обратно сообщение об ошибке передачи контроллеру А.

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

при этом система отличается тем, что:

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

система выполнена таким образом, что для осуществления автономной передачи токена, принадлежащего контроллеру A устройства, другому контроллеру B другого устройства,

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

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

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

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

(i) токен подписан сервером,

(ii) владельцем токена является контроллер A, и

(iii) токен работает в доверенной среде исполнения устройства контроллера A;

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

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

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

9. Система по п. 8, отличающаяся тем, что для осуществления операции проверки (ii) того, что владельцем токена является контроллер A, TEE устройства контроллера B выполнена с возможностью проверки, что владельцем токена является контроллер A, посредством протокола доказательства с нулевым разглашением ZKP на устройстве контроллера B в автономном режиме связи с помощью блока связи устройства контроллера А.

10. Система по любому из пп. 8 и 9, отличающаяся тем, что для осуществления операции проверки (iii) того, что токен работает в доверенной среде исполнения устройства контроллера A, TEE устройства контроллера B выполнена с возможностью проверки, что токен работает в доверенной среде исполнения устройства контроллера A, посредством динамической синхронизации/реконструкции состояния систем и протокола ZKP для подписи TEE на устройстве контроллера B в автономном режиме связи с помощью блока связи устройства контроллера A.

11. Система по любому из пп. 8–10, отличающаяся тем, что контроллер A выполнен с возможностью изменения притязания на владение токеном для работающего токена в пользу контроллера B посредством забывчивых вычислений на устройстве контроллера A в автономном режиме связи с помощью блока связи устройства контроллера B.

12. Система по любому из пп. 8–11, отличающаяся тем, что система выполнена таким образом, что при остановке работы автономного токена посредством TEE устройства контроллера B,

TEE устройства контроллера B генерирует проверяемую подпись одноразового использования, доказывающую, что автономный токен был остановлен, и содержащую доказуемую проверку оригинальной автономной подписи TEE одноразового использования, и устройство контроллера B генерирует подпись притязания на владение одноразового использования;

контроллер B добавляет в запрос на передачу проверяемую подпись одноразового использования, доказуемую проверку оригинальной автономной подписи TEE одноразового использования и подпись притязания на владение одноразового использования, а также рассылает запрос на передачу в режиме онлайн на сервер с помощью блока связи устройства контроллера B; и

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

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

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

13. Система по любому из пп. 8–10, отличающаяся тем, что система выполнена таким образом, что в случае если TEE устройства контроллера A не запускает работу токена или останавливает работу токена до его передачи на устройство контроллера B:

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

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

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

верификации того, что токен действительно находится в автономном режиме, затем

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

14. Система по любому из пп. 8–13, отличающаяся тем, что система выполнена таким образом, что в случае передачи в режиме онлайн токена, принадлежащего контроллеру А устройства, другому контроллеру B другого устройства, передачу осуществляют путем выполнения следующих операций:

отправки контроллером A контроллеру B уникального идентификатора токена, подлежащего передаче, посредством автономной связи между блоками связи устройства контроллера A и устройства контроллера B,

обратной отправки контроллером B подписи притязания на владение одноразового использования контроллера B посредством автономной связи между блоками связи устройства контроллера B и устройством контроллера A,

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

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

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

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

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