СПОСОБ И СИСТЕМА АУТЕНТИФИКАЦИИ ПОЛЬЗОВАТЕЛЯ ПОСРЕДСТВОМ МОБИЛЬНОГО УСТРОЙСТВА С ПРИМЕНЕНИЕМ СЕРТИФИКАТОВ Российский патент 2017 года по МПК H04L29/06 

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

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

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

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

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

В патентном документе США US 2011/0270751 А1 раскрыты система и способ аутентификации для двухфакторной аутентификации. Система в соответствии с указанным документом содержит сервер предоставления услуги, терминал, выполненный с возможностью использования указанного сервера, мобильное устройство, и, при необходимости, сервер, выполненный с возможностью хранения различных идентификационных данных, соединенный как с указанным мобильным устройством, так и с указанным сервером предоставления услуги. В соответствии с патентным документом США US 2011/0270751 А1 QR-код (двумерный штриховой код), отображаемый на терминале и сканируемый посредством мобильного устройства, содержит так называемый идентификатор транзакции или идентификатор сессии, а также адрес указанного сервера предоставления услуги. Так называемый «запрос аутентификации», который содержится в этом QR-коде, может быть принят пользователем путем получения изображения экрана терминала с использованием камеры мобильного устройства, либо может быть принят в сообщении электронной почты. Чтобы сервер предоставления услуги выполнил идентификацию, мобильное устройство передает идентификационные данные в сервер предоставления услуги непосредственно или из сервера, хранящего идентификационные данные.

В патентном документе США US 2012/0240204 А1 раскрыта система аутентификации пользователя, в которой пользователь принимает данные, требуемые для аутентификации, посредством сканирования QR-кода или иного пригодного для этой цели штрихового кода с терминала, соединенного с сервером предоставления услуги, с помощью своего мобильного устройства, при этом для формирования указанного QR-кода сервер предоставления услуги также использует данные, принятые от пользователя. Данные в зашифрованной форме передаются в мобильное устройство и декодируются им. Пользователь использует эти данные для аутентификации на сервере аутентификации, соединенном с сервером предоставления услуги. Сервер аутентификации проверяет принятые данные, используя базу данных идентификационной информации, и, в зависимости от результата проверки, аутентифицирует данного пользователя либо отказывает ему в аутентификации.

В патентном документе США US 2012/0166309 А1 раскрыта система, в которой для банковских транзакций используются терминал и мобильное устройство. Эти терминал и мобильное устройство обмениваются информацией с использованием штриховых кодов, например, QR-кодов. Решение, раскрытое в US 2012/0166309, имеет недостаток, состоящий в том, что при передаче данных не применяется шифрование данных, и в QR-коды включаются конфиденциальные данные. Таким образом, всякий раз QR-код содержит данные транзакции (номер карты, сумма к перечислению, номер счета и т.д.). Так как QR-коды при использовании соответствующей программы могут быть считаны кем угодно, содержащиеся в них конфиденциальные данные тоже доступны всем.

В соответствии с патентным документом US 2012/0166309 А1, данные, подлежащие подтверждению (образующие конфиденциальную информацию) передаются посредством экрана первого устройства во второе устройство (например, в мобильное устройство из терминала), и это означает, что если первое устройство скомпрометировано, то во второе устройство могут быть переданы фальсифицированные данные. Если пользователь спешит, то, выполняя обычное подтверждение транзакции на мобильном устройстве, он может подтвердить операцию, не заметив, что в ней используются фальсифицированные данные. Без использования шифрования данных при передаче ко всей конфиденциальной информации может быть получен доступ, и указанная информация может быть считана через сеть и в дальнейшем использована для совершения мошеннических действий (к примеру, для совершения мошенничества типа CNP [Card Not Present, карта отсутствует]) без ведома пользователя.

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

В статье «3.2 Using mobile devices for digital signatures» (Использование мобильных устройств для цифровой подписи), авторы Faigl, Imre, Budai (Az , , vol. LX., no. 3, pp. 30-31, 2005) описывается орган предоставления подписи, соединенный с мобильным устройством и поставщиком услуги. В соответствии с указанным документом, ключ подписи и алгоритм хранятся органом предоставления подписи, а мобильное устройство идентифицирует себя органу предоставления подписи, например, с использованием персонального идентификационного кода (кода PIN).

Системы аутентификации на основе сканирования QR-кодов раскрыты в патентных документах США US 2012/0005076 А1, US 2012/0066501 А1 и US 2012/0203646 А1. В соответствии с US 2012/0066501 А1 система состоит из мобильного устройства, выполненного с возможностью сканирования QR-кода, терминала и системы предоставления услуги. Аутентификация на основе QR-кода используется в системе для цифрового подписывания в соответствии с US 2012/0203646 А1. В US 2012/0116972 А1 раскрыта система электронной оплаты, содержащая систему управления подписями.

В патентном документе США US 2007/0130463 раскрыта система аутентификации, содержащая, помимо мобильного устройства и системы предоставления услуги, так называемую «систему аутентификации и ключей», выполненную с возможностью, например, синхронизации ключей. Системы, дающие возможность подписывания цифровой подписью для нескольких сторон, раскрыты в патентных документах США US 2011/0296191 А1 и US 2011/0314371 А1. Кроме того, системы для цифрового подписывания раскрыты в публикациях WO 2005/067402 А2, WO 2009/080999 А2 и US 2011/219427 А1. В международной публикации WO 2010/056969 А2 раскрыта система, использующая для электронных транзакций короткие сообщения (SMS). Пример использования протокола MQTT описывается в публикации J.М. Robinson, J.G. Frey, A.J. Stanford-Clark, A.D. Reynolds, В.V. Bedi: Sensor Networks and Grid Middleware for Laboratory Monitoring, Proceedings of the First International Conference on e-Science and Grid Computing (e-Science '05), Computer Society, IEEE.

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

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

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

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

В соответствии с настоящим изобретением мы поняли пользу того, что имеющиеся в продаже мобильные устройства обладают возможностью исполнения прикладных программ (к примеру, браузеров), которые дают мобильному устройству возможность осуществления аутентификации с использованием сертификатов, к примеру, типа Х.509. Следовательно, возможно применение технологии PKI (Public Key Infrastructure, инфраструктура открытого ключа) для осуществления защищенного входа (регистрации) на веб-страницы, требующие двусторонней аутентификации (предпочтительно, типа SSL [Secure Sockets Layer, уровень защищенных сокетов]), когда мобильное устройство и веб-страница взаимно идентифицируют друг друга с использованием своих соответствующих сертификатов Х.509. PKI представляет собой криптографическую технологию, дающую возможность защищенной связи по незащищенным общедоступным сетям и обеспечивающую надежную идентификацию пользователя. Как определено криптографическим протоколом SSL, для шифрования симметричных ключей, используемых в ходе установления канала SSL, следует использовать сертификаты открытого ключа, соответствующие стандарту Х.509; не допускается использование сертификатов на основе других стандартов.

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

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

В соответствии с настоящим изобретением, наивысший уровень безопасности может быть достигнут, когда секретный ключ, принадлежащий сертификату, находящемуся в мобильном устройстве, существует только в единственном экземпляре, т.е. формируется, предпочтительно, в самом мобильном устройстве. Способ формирования и упорядоченного хранения ключей в значительной мере определяет уровень защиты, достижимый для операций с использованием ключей. В устройствах под управлением операционной системы iOS (iPhone Operating System, операционная система iPhone) имеется собственное средство SCEP (Simple Certificate Enrolment Protocol, простой протокол регистрации сертификатов), выполненное с возможностью высокоэффективного формирования ключей и с возможностью передачи запросов на сертификаты в удостоверяющий центр, аутентификация в котором была осуществлена с использованием заранее согласованного пароля. Для достижения наивысшего возможного уровня безопасности функции SCEP должны, предпочтительно, быть реализованы на мобильных платформах, исполняющих другие операционные системы.

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

Способ и система в соответствии с настоящим изобретением основаны на аутентификации с использованием сертификатов, находящихся в мобильных устройствах. Эта аутентификация осуществляется с использованием протокола передачи данных HTTP, предпочтительно, через канал SSL. Характеристики протокола SSL определяются стандартом RFC 6101.

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

Поскольку в техническом решении в соответствии с настоящим изобретением ни в каком виде не используется обработка и хранение данных банковской карты в ходе операции аутентификации при электронных банковских (карточных) транзакциях, промышленный стандарт PCI DSS (Payment Card Industry Data Security Standard, стандарт защиты данных в сфере платежных карт) не относится к данному техническому решению. Однако техническое решение в соответствии с настоящим изобретением отвечает требованиям к защите банковских операций, сформулированным в PCI DSS.

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

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

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

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

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

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

Фиг. 4 иллюстрирует компоненты варианта осуществления способа и системы, показанного на фиг. 3.

Осуществление изобретения

Сопровождающие чертежи представляют компоненты способа и системы в соответствии с настоящим изобретением. Далее сначала раскрывается способ в соответствии с настоящим изобретением с указанием на некоторые компоненты системы. Затем раскрывается система в соответствии с настоящим изобретением.

Фиг. 1 посредством функциональной схемы иллюстрирует вариант осуществления способа в соответствии с настоящим изобретением. Способ в соответствии с настоящим изобретением предназначен для аутентификации пользователя 10 в объекте 16. В контексте настоящего раскрытия термин «объект» используется для обозначения любого предприятия, организации, финансовой организации, органа власти или частного лица. Как будет показано далее в связи с вариантами осуществления настоящего изобретения, цели аутентификации могу быть разными. Аутентификация может требоваться для подтверждения регистрации («входа») пользователя в объекте, для утверждения банковской транзакции или для идентификации пользователя с целью формирования цифровой подписи. Конечно, способ аутентификации в соответствии с настоящим изобретением может применяться и для других целей.

При осуществлении способа в соответствии с настоящим изобретением обращение пользователя 10, выполненное в браузере терминала 12, обнаруживается посредством модуля 20 обращения объекта 16 (модуля, предоставляющего возможность обращения в объект 16), и сетевой адрес модуля 24 аутентификации объекта 16 передается посредством модуля 20 обращения в мобильное устройство 14 пользователя 10 в сообщении аутентификации. На основании сетевого адреса мобильное устройство 14 имеет возможность обратиться к модулю 24 аутентификации. Так как мобильное устройство 14 связано с определенным пользователем, объект 16 указанным образом имеет возможность передать сообщение аутентификации пользователю 10.

Мобильным устройством 14 является, предпочтительно, интеллектуальное мобильное устройство, например, смартфон или планшет. В мобильном устройстве 14 имеется сертификат, выданный удостоверяющим центром 18, признаваемым объектом 16. Этот сертификат имеет секретный ключ пользователя длиной, по меньшей мере, 1024 бита, а, предпочтительно, 2048 бит и однозначно идентифицирует пользователя 10. Указанный секретный ключ формируется, предпочтительно, в мобильном устройстве 14, и это означает, что не существует копий указанного ключа.

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

В показанном на фиг. 1 варианте осуществления способа в соответствии с настоящим изобретением шаг проверки допустимости сертификата объекта содержит выполняемую посредством мобильного устройства 14 проверку действительности сертификата объекта в удостоверяющем центре, предоставившем сертификат объекту, и проверку благонадежности указанного удостоверяющего центра. Если сертификат модуля 24 аутентификации выдан удостоверяющим центром, который мобильное устройство 14 считает «неблагонадежным» (недоверенным), то мобильное устройство 14 прерывает обращение в модуль 24 аутентификации. В данном варианте осуществления способа шаг проверки допустимости сертификата пользователя содержит выполняемую посредством модуля 24 аутентификации проверку действительности сертификата пользователя в удостоверяющем центре, предоставившем сертификат пользователю, и проверку благонадежности указанного удостоверяющего центра. В варианте осуществления в соответствии с фиг. 1 и удостоверяющий центр, предоставивший сертификат пользователю, и удостоверяющий центр, предоставивший сертификат объекту, представляют собой удостоверяющий центр 18. В варианте осуществления на фиг. 1 модуль 24 аутентификации и удостоверяющий центр 18 связаны каналом 116 связи, который, например, реализован посредством сети Интернет. Сертификаты мобильного устройства 14 и модуля 24 аутентификации не обязательно должны выдаваться одним удостоверяющим центром. Если удостоверяющий центр, предоставивший сертификат пользователю, отличается от удостоверяющего центра, предоставившего сертификат объекту, то мобильное устройство 14 и модуль 24 аутентификации выполняют взаимную проверку благонадежности удостоверяющих центров друг друга.

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

Если и сертификат объекта, и сертификат пользователя являются допустимыми, то между мобильным устройством и модулем аутентификации устанавливается двунаправленное соединение с использованием сертификатов, предпочтительно, двунаправленный канал связи типа SSL. Перед установлением указанного канала связи выполняется взаимная проверка сертификатов (проверка благонадежности и проверка на отзыв с использованием протокола OCSP (Online Certificate Status Protocol, протокол определения состояния электронного сертификата) или списка CRL (Certificate Revocation List, список отозванных сертификатов)), за которой следует так называемая операция установления связи (подтверждения установления соединения). До проверки сертификатов никакого обмена информацией, связанного с передачей конфиденциальных данных, между мобильным устройством и модулем аутентификации не происходит.

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

Однонаправленное соединение SSL создается, когда устанавливается соединение HTTPS между клиентом (браузером) и веб-сервером; необходимо, чтобы только веб-сервер идентифицировал себя с использованием своего сертификата, которым является, предпочтительно, сертификат веб-сервера SSL типа Х.509 с открытым ключом, выданный на собственный домен этого веб-сервера и подписанный, предпочтительно, удостоверяющим центром, которому доверяют обе стороны. Клиент сможет подключиться к веб-серверу только тогда, когда этот сертификат веб-сервера прослеживается назад до сертификата доверенного удостоверяющего центра и действителен (не просрочен, не отозван и не приостановлен).

Двунаправленное соединение SSL создается, когда устанавливается соединение HTTPS между клиентом (браузером) и веб-сервером; необходимо, чтобы обе стороны (клиент и веб-сервер) идентифицировали себя с использованием своих собственных сертификатов, которыми являются, предпочтительно, сертификат веб-сервера, а также сертификаты Х.509 с открытым ключом. Клиент сможет подключиться к веб-серверу только тогда, когда этот сертификат веб-сервера прослеживается назад до сертификата доверенного удостоверяющего центра и действителен (не просрочен, не отозван и не приостановлен). Кроме того, веб-сервер даст клиенту возможность подключиться только тогда, когда сертификат аутентификации клиента выдан доверенной стороной и действителен (не просрочен, не отозван и не приостановлен).

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

В соответствии с заявкой США US 2012/0240204 А1, после того, как сервер аутентификации проверен клиентом, между мобильным устройством и сервером аутентификации устанавливают канал связи. Затем через этот канал передаются фактические данные авторизации, допускающей данного пользователя, и эти данные используются для идентификации клиента и для подтверждения транзакции.

В противоположность этому, в способе в соответствии с настоящим изобретением аутентификация осуществляется как результат установления канала связи, то есть операция установления канала связи включает в себя и аутентификацию.

Способ аутентификации в соответствии с настоящим изобретением является более эффективным по сравнению с решением известного уровня техники согласно документу US 2012/0240204 А1, так как раскрытое в данном документе техническое решение не содержит проверку клиента сервером аутентификации банка перед установлением канала связи. Этот недостаток технического решения согласно документу US 2012/0240204 А1 может быть использован злоумышленником следующим образом.

Получив контроль над компьютером клиента или включившись в сеть между этим компьютером и сервером (эквивалентным модулю обращения настоящего изобретения) поставщика услуги в соответствии с указанным документом, злоумышленник может подменить содержащийся в QR-коде идентификатор URL (Uniform Resource Locator, унифицированный идентификатор ресурса), т.е. сетевой адрес сервера аутентификации, имеющего действительный, доверенный сертификат SSL, собственным сетевым адресом, который может в значительной мере быть похожим на реальный URL указанного сервера аутентификации. В результате, в соответствии с техническим решением, раскрытым в указанном документе, мобильное устройство будет считать фальшивый сервер аутентификации (сервер злоумышленника) благонадежным, так как у него может быть действительный сертификат (получить сертификат SSL для своего домена может кто угодно). После успешного установления однонаправленного канала связи HTTPS с фальшивым сервером клиент передает данные авторизации (OTP, PIN, данные, подписанные ключом и т.д.) в сервер злоумышленника. Злоумышленник после этого может установить реальное однонаправленное соединение SSL с реальным сервером аутентификации и передать в него данные авторизации, указанные клиентом, и тем самым воспользоваться этими данными в своих интересах.

В отличие от этого в способе в соответствии с настоящим изобретением для установления канала связи мобильное устройство 14 должно представить в модуль 24 аутентификации действительный сертификат. Иными словами, между мобильным устройством и модулем аутентификации должно быть установлено двунаправленное соединение SSL, которое не даст возможности осуществить вышеописанную «атаку посредника» следующим образом. Если описанным выше способом злоумышленник передаст в мобильное устройство 14 в сообщении аутентификации фальшивый сетевой адрес в качестве сетевого адреса модуля аутентификации, примет из мобильного устройства сертификаты аутентификации, выданные тем же самым доверенным удостоверяющим центром, например, для установления соединения, к примеру, канала связи HTTPS, то после того, как канал связи будет установлен, злоумышленник сможет получить от пользователя указанные косвенные данные авторизации. Однако злоумышленник не сможет использовать полученные данные авторизации в своих интересах, поскольку не сможет подключиться к реальному модулю аутентификации, выдавая себя за пользователя (то есть использовать секретный ключ пользователя и сертификат, хранящиеся в мобильном устройстве), поскольку у него нет секретного ключа пользователя.

Таким образом, в способе, раскрытом в документе US 2012/0240204 А1, чтобы сравнительно легко получить контроль над операцией авторизации, злоумышленнику достаточно взломать компьютер, например, терминал (который может, к примеру, находиться в интернет-кафе). Однако в техническом решении в соответствии с настоящим изобретением злоумышленник не сможет воспользоваться полученными данными в своих интересах, когда скомпрометирована только одна из сторон.

В варианте осуществления, показанном на фиг. 1, обращение с использованием имени учетной записи (логина) инициируется в модуле 20 обращения через канал 100 связи, при этом терминал 12 отображает регистрационный интерфейс объекта 16. Канал 100 связи может быть установлен, например, с использованием сети Интернет.

В способе в соответствии с настоящим изобретением как терминал 12, так и мобильное устройство 14 тем или иным образом (Wi-Fi, 3G, GPRS и т.д.) подключены к интернету. Способы (услуги объекта) в соответствии с вариантами осуществления настоящего изобретения могут быть реализованы таким образом, что пользователи и клиенты получают доступ к отдельным модулям объекта 16 через интернет.

В соответствии с данным вариантом осуществления пользователь 10 (владеющий мобильным устройством 14) сначала, используя браузер терминала 12, входит на основную веб-страницу объекта 16 (то есть в модуль 20 обращения), которая требует простой аутентификации по имени учетной записи и паролю с использованием соединения (предпочтительно однонаправленного) по протоколу HTTPS передачи данных.

После успешной аутентификации по имени учетной записи и паролю объект 16 пока не предоставляет пользователю 10 доступ к модулю 20 обращения. Вместо этого объект 16 возвращает сетевой адрес, то есть URL модуля 24 аутентификации. Поэтому и модуль 20 обращения, и модуль 24 аутентификации могут быть осуществлены в виде соответствующей веб-страницы. Затем пользователь, используя свое мобильное устройство 14, открывает страницу по сетевому адресу модуля 24 аутентификации. Для соединения с модулем 24 аутентификации нужен секретный ключ (например, типа RSA) и соответствующий сертификат аутентификации (например, типа Х.509), выданный на имя пользователя. И секретный ключ, и сертификат хранятся в мобильном устройстве. Как показано ниже, ссылка, передаваемая модулем 20 обращения, содержит сетевой адрес модуля 24 аутентификации (URL его веб-страницы: https://<secondary-website>) и, предпочтительно, значение идентификатора транзакции, соответствующее вышеописанной регистрации по имени учетной записи и паролю, выполненной с использованием модуля обращения.

Соответственно, URL, требуемый для подтверждения аутентификации, строится как https://<secondary-website>/?trid=ϕ(trid),

где ϕ - симметричный ключ банка/организации;

trid - идентификатор транзакции, а

ϕ(trid) - идентификатор trid, зашифрованный с использованием ключа ϕ.

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

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

В качестве сообщения аутентификации может использоваться QR-код, и в этом случае сетевой адрес передается в мобильное устройство 14 путем выполнения следующих шагов. После ввода имени учетной записи и пароля модуль 20 обращения в QR-коде, отображаемом на экране терминала 12, предъявляет пользователю URL модуля аутентификации объекта 16, запрашивающего аутентификацию клиента SSL с использованием сертификата, и текущий идентификатор транзакции. Соответственно, указанный QR-код передается в терминал 12 модулем 20 обращения; затем данный код отображается на дисплее терминала 12 и фотографируется устройством получения изображений мобильного устройства 14 и в результате передается в мобильное устройство 14. Таким образом сообщение аутентификации передается из модуля 20 обращения в мобильное устройство 14. В варианте осуществления, показанном на фиг. 1, QR-код передается в терминал 12 через канал 102 связи, к примеру, через сеть интернет, и затем передается с использованием канала 104 связи, то есть, как описано выше, путем фотографирования указанного QR-кода.

Сообщение из модуля 20 обращения также может, предпочтительно, поступать в мобильное устройство 14 в виде сообщения типа очереди сообщений («сообщение MQ», Message Queue, очередь сообщений), предпочтительно, сообщения типа MQ-TT (очередь сообщений передачи телеметрии). Очереди сообщений реализуют асинхронный протокол связи, что означает, что отправитель и получатель сообщения не обязательно должны подключаться к очереди сообщений одновременно. Сообщение передается отправителем в очередь сообщений, где сохраняется и ожидает доставки до тех пор, пока получатель не получит его из очереди сообщений. Сообщения, принимаемые очередью сообщений, могут быть ограничены в размере, время хранения сообщения в очереди также может быть ограничено.

Есть несколько типов протокола MQ (к примеру, AMQP, MQTT, STOMP), и каждый из них имеет несколько вариантов реализации (например, IBM WebSphere MQ, Apache ActiveMQ, RabbitMQ), но базовая функциональность, а именно сохранение сообщений в очереди доставки, одна и та же.

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

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

В этом случае интеллектуальное мобильное устройство использует пригодную для этой цели клиентскую программу для соединения с модулем 26 очереди сообщений объекта 16; соединение осуществляется посредством протокола MQ, реализованного с использованием разнонаправленных каналов 108, 110 связи, показанных на фиг. 1. Соединение с модулем 26 очереди сообщений обычно выполняется с использованием аутентификации некоторого типа (например, аутентификации, использующей имя пользователя и пароль). Серверы, используемые для обслуживания модуля 20 обращения и модуля 24 аутентификации учреждения 16, выполнены с возможностью передачи сообщений через модуль 26 очереди сообщений в подключенные мобильные устройства 14. На фиг. 1 показаны двунаправленные каналы 106, 112 связи, используемые для соединения с модулем 20 обращения и с модулем 26 очереди сообщений. В варианте осуществления, показанном на фиг. 1, модуль 24 аутентификации выполнен с возможностью непрямой передачи сообщений типа очереди сообщений (далее сообщений MQ) через канал 118 связи.

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

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

Сообщение аутентификации (и введенный в него URL модуля аутентификации) может быть передано в мобильное устройство 14 с использованием SMS (short text message, короткое текстовое сообщение). Поставщики услуг SMS не гарантируют немедленную передачу и доставку сообщений.

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

Также может быть подготовлена резервная схема передачи сообщений, в которой канал передачи сообщений при его недоступности заменяется запасным каналом передачи сообщений. Для иллюстрации этой резервной схемы на фиг. 1 показаны каналы 102, 104 связи, выполненные с возможностью передачи QR-кода, и каналы 108, 110, 106 и 112 связи, выполненные с возможностью передачи сообщения MQ.

После приема сообщения аутентификации, переданного в QR-коде, сообщении MQ, SMS, push-сообщении или в сообщении электронной почты, мобильное устройство 14 соединяется с принятым сетевым адресом, конкретно, с сетевым адресом модуля 24 аутентификации, используя свой секретный ключ и соответствующий сертификат аутентификации типа Х.509. В соответствии с фиг. 1 это соединение, то есть открытие сетевого адреса модуля 24 аутентификации, реализуется с использованием канала 114 связи. Канал 114 связи может быть установлен, например, с использованием сети Интернет.

Модуль 24 аутентификации затем, используя, предпочтительно, OCSP или CRL, проверяет в удостоверяющем центре 18, не отозван ли сертификат клиента. Если сертификат, содержащийся в мобильном устройстве 14, недействителен (приостановлен, отозван, или проверить его не удалось), то в мобильное устройство 14 через канал 120 связи и в модуль 20 обращения через канал 118 связи передается сообщение об ошибке.

Если объект 16 осуществляет связь с мобильным устройством через соединение MQ, то извещение о неуспешной аутентификации также может передаваться в это мобильное устройство в сообщении MQ, передаваемом через каналы 106, 108 связи.

Если сертификат, находящийся в мобильном устройстве, действителен, и, предпочтительно, если содержащиеся в нем данные были приняты и идентификатор транзакции указывает на успешно выполненную модулем 20 обращения аутентификацию, то из модуля 24 аутентификации в мобильное устройство 14 через канал связи 120 передается сообщение, извещающее об успешной аутентификации. Как и канал 114 связи, канал 120 связи, предпочтительно, реализован с использованием сети Интернет. Если объект 16 осуществляет связь с мобильным устройством 14 через соединение MQ, то извещение об успешной аутентификации передается в это мобильное устройство также в сообщении MQ. В качестве последнего шага после успешной авторизации модуль 20 обращения объекта 16 обеспечивает регистрацию (вход) пользователя.

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

В исходном состоянии шага одобрения транзакции пользователь 10, имеющий мобильное устройство 14, выполнил регистрацию в модуле 20 обращения объекта 16 в браузере терминала 12. В данном варианте осуществления объектом 16 является, предпочтительно, банк. Доступ к сетевому интерфейсу модуля 20 обращения может осуществляться с использованием однонаправленного канала связи HTTPS. Зарегистрировавшийся пользователь 10 инициирует транзакцию (например, денежный перевод) и заполняет форму данной транзакции. На следующей странице банк отображает подлежащую утверждению пользователем информацию о транзакции, и пользователь утверждает данные транзакции в браузере своего компьютера.

Банк затем передает сетевой адрес модуля аутентификации в сообщении аутентификации в мобильное устройство 14, а пользователь открывает указанное сообщение, используя свое мобильное устройство 14. Как и в вышеописанном случае, для соединения с модулем 24 аутентификации требуются секретный ключ и принадлежащий ему сертификат (хранящиеся в мобильном устройстве 14); отличие в том, что в данном варианте осуществления целью аутентификации, выполняемой модулем 24 аутентификации, является утверждение транзакции. Как и в вышеописанном случае, ссылка, переданная из модуля 20 обращения, содержит URL (https://<secondary-website>) модуля 24 аутентификации, а также, в качестве значения, идентификатор транзакции, соответствующий данной транзакции.

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

И в данном варианте осуществления сообщение аутентификации может быть передано в мобильное устройство 14 через вышеописанные каналы (QR-код, сообщение MQ, push-сообщение, электронная почта, SMS).

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

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

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

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

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

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

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

Затем, если пользователь 10 уже аутентифицирован и зарегистрирован в системе с использованием способа в соответствии с настоящим изобретением, как описано выше, то объект 16 вводит сертификат пользователя в созданный указанным образом документ, при этом сертификат пользователя снабжен ключом подписи пользователя и в фоновом режиме принимается из модуля 28 предоставления ключа, соединенного с объектом 16, с использованием информации, однозначно идентифицирующей пользователя в модуле 28 предоставления ключа. Чтобы осуществить это, объект 16 должен знать, какой орган предоставления ключа предоставил используемый в данный момент ключ подписи пользователя 10 (он может быть указан заранее пользователем 10).

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

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

Согласно фиг. 2, имеется возможность выбирать сертификат подписывающего лица, относящийся к пользователю 10, даже когда пользователь 10 осуществляет доступ к модулю 20 предоставления ключа объекта 16 анонимно или после аутентификации способом, не использующим сертификат. В этом случае сертификат подписывающего лица запрашивается из модуля 26 предоставления ключа не объектом 16, а мобильным устройством 14 пользователя 10.

В данном варианте осуществления, чтобы сделать возможным выполнение указанной операции подписания, модуль 20 обращения используется для передачи сетевого адреса (URL) модуля 28 предоставления ключа в мобильное устройство 14 в сообщении аутентификации. Параметр сетевого адреса содержит адрес объекта 16, на который модуль 26 предоставления ключа должен передать сертификат подписывающего лица, относящийся к пользователю 10. Затем мобильное устройство 14 перенаправляется на модуль 20 обращения объекта 16, где указанная операция подписания продолжается.

Объект 16 затем формирует хэш-сумму документа, дополненного своим сертификатом подписывающего лица и подготовленного к подписанию пользователем 10. Тип использованного алгоритма (sha1, sha256, sha384, sha512) вычисления хэш-суммы должен быть, предпочтительно, указан в начале сформированного значения хэш-суммы. Документ, подлежащий подписанию и идентифицируемый указанной хэш-суммой, следовательно, уже содержит сертификат подписывающего лица учреждения 16.

В данном варианте осуществления роль модуля аутентификации выполняет модуль 28 предоставления ключа. Соответственно, ссылка, подлежащая передаче в мобильное устройство 14 в сообщении аутентификации, формируется модулем 20 обращения описанным далее образом. Указанная ссылка содержит адрес веб-сайта модуля 28 предоставления ключа, который запрашивает сертификат аутентификации (то есть сетевой адрес).

В указанном URL

https://<адрес органа предоставления ключа>/?id=<id>&par=ϕ(par)

задаются следующие параметры GET:

id - уникальный идентификатор объекта 16, известный данному модулю предоставления ключа;

par - параметры, зашифрованные с использованием симметричного ключа (ϕ), известного объекту 16 и модулю 28 предоставления ключа,

hash - хэш-сумма документа, подлежащего подписанию,

trid - идентификатор транзакции,

userid - уникальный идентификатор пользователя 10, известный объекту 16 и модулю 28 предоставления ключа,

дополнительные параметры, задаваемые при необходимости.

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

Как и в вышеописанном случае, сформированная ссылка (сетевой адрес) предъявляется пользователю 10 модулем 20 обращения в QR-коде посредством терминала 12 или в сообщении MQ, в SMS, push-сообщении или в сообщении электронной почты, но сообщение аутентификации также может быть передано в мобильное устройство 14 из терминала 12 через канал bluetooth. При использовании QR-кодов или сообщений типа очереди сообщений используются вышеупомянутые каналы связи 100, 102, 104, 106, 108, 110, 112.

Пользователь 10 затем считывает QR-код, отображаемый модулем 20 обращения, с использованием программы считывания QR-кодов, работающей на его мобильном устройстве, или открывает (к примеру, в браузере или в другой программе) ссылку, принятую в сообщении типа очереди сообщений, в SMS, в push-сообщении или в сообщении электронной почты. Если ссылка принята мобильным устройством в сообщении MQ, то указанное мобильное устройство может передавать подписанное уведомление о получении, относящееся к принятому сообщению MQ, через модуль 26 очереди сообщений, используя ключ подписи, хранящийся, предпочтительно, в мобильном устройстве 14.

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

Затем в мобильном устройстве 14 выполняется аутентификация вышеописанным способом с использованием сертификата, модуля 28 предоставления ключа и канала 126 связи между модулем 28 предоставления ключа и удостоверяющим центром 18. Модуль 28 предоставления ключа при этом совместно с удостоверяющим центром 18 проверяет, не отозван ли сертификат пользователя, используя для этого протокол OCSP (Online Certificate Status Protocol) или список CRL (список отозванных сертификатов). Если сертификат недействителен (приостановлен, отозван или проверить его не удалось), или действителен, но в модуле 28 предоставления ключа нет соответствующего ключа подписи или ключа шифрования, то в мобильное устройство 14 и в модуль 20 обращения из модуля 28 предоставления ключа передается сообщение об ошибке.

Если аутентификация прошла успешно, то есть двусторонняя проверка сертификатов успешно выполнена, то ключ подписи пользователя 10 (хранящийся в модуле хранения ключа, соединенном с модулем 28 предоставления ключа) однозначно идентифицирован модулем 28 предоставления ключа с использованием сертификата пользователя. Модуль хранения ключа реализуется, предпочтительно, в виде так называемого модуля HSM (Hardware Security Module, аппаратный модуль защиты). На следующем шаге модуль 28 предоставления ключа считывает из своей базы данных симметричный ключ шифрования или пароль, являющиеся общими с объектом 16, используя незашифрованный параметр «id», ранее переданный вместе со ссылкой, дешифрует зашифрованный параметр GET и использует его для формирования остальных требуемых параметров.

Используя ключ, хранящийся в указанном модуле HSM, и применяя аутентификацию с использованием сертификата, модуль предоставления ключа подписывает хэш-сумму, полученную дешифрованием зашифрованного параметра GET. Затем модуль 28 предоставления ключа через соединение HTTPS уведомляет объект 16, указанный в параметре GET, о том, что модуль 28 предоставления ключа имеет хэш-сумму, подлежащую передаче в учреждение 16, и эта хэш-сумма подписана пользователем 10 объекта 16.

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

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

Документ, содержащий хэш-сумму и подписанный объектом 16, проверяется модулем 28 предоставления ключа. Если установлено, что подпись действительна и хэш-сумма, содержащаяся в подписанном документе, совпадает с хэш-суммой, переданной пользователем 10 в параметре GET, то считается подтвержденным факт того, что подписание данной хэш-суммы было запрошено объектом 16, и поэтому данная хэш-сумма не фальсифицирована. Затем модуль 28 предоставления ключа передает хэш-сумму, подписанную пользователем 10, в объект 16. Данная хэш-сумма, подписанная электронной подписью объекта 16, сохраняется модулем предоставления ключа в архиве в качестве доказательства. Позднее с использованием этого документа модуль 28 предоставления ключа сможет доказать, что он с использованием ключа пользователя 10 подписывал хэш-сумму, относящуюся к документу, подписание которого запрашивалось третьей стороной, объектом 16.

Затем модуль 20 обращения извещает пользователя 10 об успешном или неуспешном завершении операции подписания, делая это, предпочтительно, и через терминал 12, и через модуль 26 очереди сообщений (если такой канал связи установлен между объектом и мобильным устройством клиента).

Шаги, выполняемые при осуществлении данного варианта реализации, могут быть изложены следующим образом: посредством модуля 20 обращения обнаруживается обращение с целью подписания документа; с использованием данных, запрашиваемых у пользователя 10, подготавливается контракт, подписываемый объектом 16 и предлагаемый к подписанию пользователю 10; и формируется хэш-сумма контракта. В настоящем варианте осуществления модулем аутентификации является модуль 28 предоставления ключа. Затем, в соответствии с данным вариантом осуществления, посредством модуля 20 обращения сетевой адрес модуля 24 предоставления ключа передается в мобильное устройство 14 пользователя 10 в сообщении аутентификации; в указанном сообщении аутентификации также передается зашифрованная хэш-сумма. Далее, если канал связи между мобильным устройством 14 и модулем 28 предоставления ключа установлен (то есть аутентификация выполнена успешно), то эта зашифрованная хэш-сумма и идентификатор объекта 16 передаются в модуль 28 предоставления ключа, объект 16 идентифицируется модулем 28 предоставления ключа, и зашифрованная хэш-сумма дешифруется посредством ключа, присвоенного объекту 16, после этого указанная хэш-сумма подписывается с использованием ключа пользователя 10, к которому модуль 28 предоставления ключа имеет доступ, и затем, после подтверждения в объекте 16 того, что данная хэш-сумма была принята из объекта 16, эта хэш-сумма передается из модуля 28 предоставления ключа в объект 16.

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

В настоящем варианте осуществления мобильное устройство 14 осуществляет связь с модулем 28 предоставления ключа через каналы 122 и 124 связи; канал 122 связи направлен из мобильного устройства 14 в модуль 28 предоставления ключа, а канал 124 связи направлен в обратном направлении. Модуль 28 предоставления ключа соединен с модулем 20 обращения через каналы 128 и 130 связи; канал 128 связи направлен из модуля 28 предоставления ключа в модуль 20 обращения, а канал 130 связи направлен в обратном направлении.

Подробно описанный выше вариант осуществления реализует функцию распределенной цифровой подписи, которая дает пользователю и объекту возможность подписывать документы (например, контракты), с которыми они согласны. Наиболее важная особенность схемы распределенной цифровой подписи состоит в том, что объект никогда не обладает секретным ключом подписи клиента, который клиент хранит либо в интеллектуальном мобильном устройстве, либо у доверенной третьей стороны (в вышеописанном варианте реализации - в модуле предоставления ключа). В ходе операции подписания подлежащие подписанию документы готовятся объектом в формате, соответствующем стандарту цифровой подписи (к примеру, XAdES, PAdES). Сама операция подписания выполняется не объектом, а мобильным устройством пользователя или доверенной третьей стороной (модулем предоставления ключа) после аутентификации с использованием сертификата, находящегося в мобильном устройстве. Мобильное устройство пользователя принимает только хэш-сумму документа, подлежащего подписанию, которая формируется объектом. Эта хэш-сумма подписывается либо с использованием секретного ключа подписывающей стороны, хранящегося в мобильном устройстве, либо, после передачи этой хэш-суммы в модуль предоставления ключа, с использованием защищенного аппаратно HSM ключа, хранящегося в этом модуле. Модуль предоставления ключа, поскольку принимает только хэш-сумму, не имеет доступа к информационному содержанию подписываемых документов. Подписанная хэш-сумма передается обратно в объект либо из мобильного устройства, либо из модуля предоставления ключа; объект вставляет эту хэш-сумму в незаконченный документ, который был подготовлен для подписания. Операция подписания клиентом на этом завершается, а объект может добавить дополнительные подписи или отметки времени. На каждом этапе операции подписания объект от всех сторон запрашивает аутентификацию с использованием сертификата. В дополнение к обеспечению безопасной идентификации пользователя, использование такой принадлежащей объекту системы подписывания дает возможность реализации администрирования с доверием на основе дистанционного подписывания электронной подписью.

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

В данном варианте осуществления у пользователя/клиента есть зашифрованный для него документ, полученный им, к примеру, как вложение в сообщение электронной почты или иным способом. Сначала, в качестве шага обращения в операции дешифрования документа, пользователь передает (загружает) документ, подлежащий дешифрованию, в модуль обращения, то есть, например, передает его в сообщении электронной почты. Затем модуль обращения выделяет из загруженного зашифрованного документа симметричный ключ, использованный для шифрования этого документа. Симметричный ключ был зашифрован с использованием сертификата шифрования пользователя. Модуль обращения формирует ссылку, которая должна быть передана в мобильное устройство пользователя. Как и в вышеописанном случае, модулем аутентификации является модуль предоставления ключа. Указанная ссылка содержит сетевой адрес модуля аутентификации. В указанном URL

https://<address of key provider>/?id=<id>&par=ϕ(par)

задаются следующие параметры GET:

id - идентификатор объекта;

par - параметры, зашифрованные с использованием симметричного ключа (ϕ), известного объекту и органу предоставления ключа,

encryptedkey - симметричный ключ, зашифрованный с использованием сертификата пользователя;

trid - идентификатор транзакции;

userid - уникальный идентификатор пользователя (к примеру, адрес электронной почты).

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

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

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

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

Еще один вариант осуществления настоящего изобретения представлен на фиг. 3. В соответствии с данным вариантом осуществления объектом 16 является банк 25, выпустивший карту, а обращение пользователя 10, состоявшееся путем передачи данных кредитной карты через платежный интерфейс интернет-магазина на терминале 12, обнаруживается посредством модуля 20 обращения банка 25, выпустившего карту, через сервер 30 интернет-магазина, сервер 32 организации, предоставляющей банковские услуги этому интернет-магазину, и сервер 34 компании по обслуживанию кредитных карт. В данном варианте осуществления в качестве сообщения аутентификации используется сообщение типа очереди сообщений, короткое текстовое сообщение (SMS), push-сообщение или сообщение электронной почты. В данном варианте осуществления в качестве сообщения аутентификации не используются QR-коды, так как терминал 12 используется для отображения платежного интерфейса интернет-магазина, в котором нет технической возможности отображения QR-кода.

В данном варианте осуществления изобретения пользователь 10 (клиент), владеющий мобильным устройством 14, инициирует в браузере терминала 12 транзакцию платежа с использованием карты (карточного платежа). Информация данной транзакции карточного платежа, введенная пользователем в интерфейсе интернет-магазина, передается через сервер 32 организации, предоставляющей банковские услуги интернет-магазину, и сервер 34 компании по обслуживанию кредитных карт и в итоге принимается банком 25, выпустившим карту.

Банк 25, выпустивший карту, проверяет данные, относящиеся к данному платежу с использованием карты: удостоверяется, что карта существует, не блокирована и обеспечена денежными средствами. Если проверка пройдена успешно, то до подтверждения транзакции пользователю передается сообщение аутентификации, извещающее о необходимости подтвердить данный карточный платеж. Это сообщение аутентификации может быть передано с использованием протокола MQ или других средств передачи сообщений (SMS, push-сообщения, электронная почта). Если используется передача сообщения MQ, то интеллектуальное мобильное устройство держателя карты должно быть подключено к модулю 26 очереди сообщений банка 25, выпустившего карту.

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

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

https://<secondary-website>/?trid=ϕ(trid),

где ϕ - симметричный ключ банка, выпустившего карту;

trid - идентификатор транзакции (например, идентификатор транзакции карточного платежа);

ϕ(trid) - идентификатор trid, зашифрованный с использованием ключа ϕ.

После передачи сообщения аутентификации мобильное устройство 14 использует свой секретный ключ и относящийся к этому ключу сертификат для подключения к модулю 24 аутентификации банка 25, выпустившего карту, который запрашивает аутентификацию с использованием сертификата и который может быть обнаружен по сетевому адресу, переданному в сообщении MQ, в SMS, push-сообщении или в сообщении электронной почты.

Как и в вышеописанном случае, модуль 24 аутентификации банка 25, выпустившего карту, с использованием OCSP или CRL проверяет, не отозван ли сертификат клиента (находящийся в мобильном устройстве 14 клиента). Кроме того, мобильное устройство 14 проверяет сертификат модуля 24 аутентификации. Если сертификат мобильного устройства недействителен (приостановлен, отозван или проверить его не удалось), то в интеллектуальное мобильное устройство передается сообщение об ошибке. Если банк 25, выпустивший карту, осуществляет связь с мобильным устройством клиента через соединение MQ, то извещение о неуспешной аутентификации также передается в мобильное устройство в сообщении MQ.

Если подтверждение по какой-либо причине (недействительный сертификат, отказ, превышение лимита времени) не состоялось, то банк, выпустивший карту, передает в сервер 30 интернет-магазина через сервер 34 компании по обслуживанию кредитных карт и сервер 32 организации, предоставляющей банковские услуги, сообщение об отказе. Результат транзакции карточного платежа отображается на дисплее терминала 12.

Если аутентификация выполнена успешно, и если данные, содержащиеся в сертификате, и аутентификация (на основании идентификатора транзакции с использованием карты) были приняты модулем 20 обращения банка 25, выпустившего карту, то данные транзакции карточного платежа передаются обратно в мобильное устройство 14 из модуля 24 аутентификации банка 25, выпустившего карту. На данном этапе транзакция еще не одобрена в мобильном устройстве.

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

Если банк 25, выпустивший карту, осуществляет связь с мобильным устройством через соединение MQ, то мобильное устройство извещается об успешном одобрении или неуспешном завершении (вследствие отказа) транзакции также в сообщении MQ.

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

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

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

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

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

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

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

- использование сообщений SMS может потребовать значительных дополнительных накладных расходов.

Вариант осуществления настоящего изобретения, в котором сообщение аутентификации передается в сообщении MQ, устраняет эти недостатки. Банк 25, выпустивший карту, может синхронно передавать сообщение в мобильное устройство, подключенное через модуль 26 очереди сообщений, без участия внешнего поставщика услуг. Как и в транзакции банковского перевода, это сообщение содержит сетевой адрес модуля 24 аутентификации и идентификатор, соответствующий транзакции с использованием карты, включаемый в сообщение в качестве параметра. Данное сообщение MQ не содержит никаких критически важных данных. Транзакция может быть проверена, подтверждена или отклонена на мобильном устройстве только после успешной аутентификации. Ключ подписи, находящийся в мобильном устройстве, может использоваться для передачи уведомления о получении сообщения MQ, принятого из банка, выпустившего карту. Указанное уведомление о получении может сохраняться в архиве системой банка, выпустившего карту, в качестве подтверждения транзакции.

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

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

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

Вариант осуществления настоящего изобретения относится к системе аутентификации пользователя в объекте. Система в соответствии с настоящим изобретением содержит модуль 20 обращения, выполненный с возможностью обнаружения обращения пользователя 10 в объект 16, терминал 12, выполненный с возможностью приема обращения, инициированного пользователем 10, с использованием модуля 20 обращения, модуль 24 аутентификации, выполненный с возможностью аутентификации пользователя 10, и мобильное устройство 14, выполненное с возможностью приема сетевого адреса модуля 24 аутентификации в сообщении аутентификации из модуля 20 обращения. В системе в соответствии с настоящим изобретением мобильное устройство выполнено с возможностью проверки допустимости сертификата объекта модуля 24 аутентификации на основании указанного сетевого адреса, а модуль 24 аутентификации выполнен с возможностью проверки допустимости сертификата пользователя мобильного устройства 14, и если указанные сертификат учреждения и сертификат пользователя являются допустимыми, то пользователь 10 аутентифицируется системой в объекте 16 с установлением канала связи между мобильным устройством 14 и модулем 24 аутентификации, а если сертификат объекта или сертификат пользователя не является допустимым, то пользователь 10 получает отказ в объекте 16.

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

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

1. Способ аутентификации пользователя (10) в объекте (16), включающий шаги обнаружения, посредством модуля (20) обращения объекта (16), обращения пользователя (10), выполненного в браузере терминала (12), и передачи, посредством модуля (20) обращения, сетевого адреса модуля (24) аутентификации объекта (16) в мобильное устройство (14) пользователя (10) в сообщении аутентификации, отличающийся тем, что, используя сообщение типа очереди сообщений в качестве сообщения аутентификации, указанное сообщение передают посредством модуля (26) очереди сообщений, соответствующего объекту (16), а подписанное ключом пользователя (10) уведомление о получении передают из мобильного устройства (14) в модуль (20) обращения после того, как указанное сообщение типа очереди сообщений принято мобильным устройством (14), находящимся в соединении с модулем (26) очереди сообщений; проверяют допустимость сертификата объекта модуля (24) аутентификации посредством мобильного устройства (14) на основании сетевого адреса и проверяют допустимость сертификата пользователя мобильного устройства (14) посредством модуля (24) аутентификации; и если сертификат объекта и сертификат пользователя являются допустимыми, то аутентифицируют пользователя (10) в объекте (16) путем установления канала (114, 120, 122, 124) связи между мобильным устройством (14) и модулем (24) аутентификации, а если сертификат объекта или сертификат пользователя не являются допустимыми, то пользователю (10) отказывают в аутентификации в объекте (16).

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

3. Способ по п. 2, отличающийся тем, что удостоверяющий центр (18), предоставивший сертификат объекту, соответствует секретному ключу объекта модуля (24) аутентификации, а сертификат объекта подписан удостоверяющим центром (18), предоставившим сертификат объекту; и удостоверяющий центр (18), предоставивший сертификат пользователю, соответствует секретному ключу пользователя мобильного устройства (14), а сертификат пользователя подписан удостоверяющим центром (18), предоставившим сертификат пользователю.

4. Способ по п. 3, отличающийся тем, что секретный ключ пользователя сформирован в мобильном устройстве (14).

5. Способ по п. 1, отличающийся тем, что объектом (16) является банк (25), выпустивший карту, и обращение пользователя (10), состоявшееся путем передачи данных кредитной карты через платежный интерфейс интернет-магазина на терминале (12), обнаруживают посредством модуля (20) обращения банка (25), выпустившего карту, через сервер (30) интернет-магазина, сервер (32) организации, предоставляющей банковские услуги данному интернет-магазину, и сервер (34) компании по обслуживанию кредитных карт.

6. Способ по п. 5, отличающийся тем, что если между мобильным устройством (14) и модулем (24) аутентификации установлен канал связи, то в мобильное устройство (14) передают данные платежа интернет-магазина и принимают информацию об авторизации или отклонении данных платежа пользователем (10).

7. Способ по любому из пп. 1-6, отличающийся тем, что посредством модуля (20) обращения обнаруживают обращение регистрации на терминале (12), отображающем регистрационный интерфейс объекта (16), и, если между модулем (24) аутентификации и мобильным устройством (14) установлен канал (114, 120, 122, 124) связи, то разрешают регистрацию пользователя (10) в объекте (16).

8. Способ по п. 7, отличающийся тем, что после того, как регистрация выполнена, готовят контракт, подлежащий подписанию пользователем (10) и объектом (16), используя данные, запрошенные от пользователя (10), и подписывают контракт ключом подписи объекта (16) и ключом подписи пользователя (10), загруженным из модуля (28) предоставления ключа.

9. Способ по любому из пп. 1-6, отличающийся тем, что посредством модуля (20) обращения обнаруживают обращение с целью подписания документа; с использованием данных, запрошенных у пользователя (10), готовят контракт, подписанный объектом (16) и подлежащий подписанию пользователем (10), и формируют хэш-сумму указанного контракта; модулем аутентификации является модуль (28) предоставления ключа, при этом сетевой адрес модуля (28) предоставления ключа передают в мобильное устройство (14) пользователя (10) в сообщении аутентификации посредством модуля (20) обращения, а хэш-сумму передают зашифрованной в указанном сообщении аутентификации; если канал связи между мобильным устройством (14) и модулем (28) предоставления ключа установлен, то передают зашифрованную хэш-сумму и идентификатор объекта (16) в модуль (28) предоставления ключа, идентифицируют объект (16) посредством модуля (28) предоставления ключа и дешифруют указанную зашифрованную хэш-сумму посредством ключа, присвоенного объекту (16), а затем подписывают хэш-сумму ключом пользователя (10), находящимся в модуле (28) предоставления ключа, и передают хэш-сумму в объект (16) из модуля (28) предоставления ключа, проверяя совместно с объектом (16), действительно ли хэш-сумма была принята из объекта (16).

10. Способ по любому из пп. 1-6, отличающийся тем, что посредством модуля (20) обращения обнаруживают обращение с целью дешифрования документа, при этом в ходе обращения пользователь (10) передает документ, подлежащий дешифрованию, в модуль (20) обращения; модулем аутентификации является модуль (28) предоставления ключа, и сетевой адрес модуля (28) предоставления ключа передают в мобильное устройство (14) пользователя (10) в сообщении аутентификации посредством модуля (20) обращения, который содержит зашифрованный симметричный ключ, зашифрованный общим с объектом (16) симметричным ключом; если канал связи между мобильным устройством (14) и модулем (28) предоставления ключа установлен, то модуль (28) предоставления ключа идентифицирует ключ дешифрования пользователя (10), используя сертификат пользователя, извлекает, используя параметр, идентифицирующий модуль (20) обращения, из своей базы данных симметричный ключ, общий с объектом (16), и формирует зашифрованный симметричный ключ путем дешифрования посредством симметричного ключа, общего с объектом (16), дешифрует зашифрованный симметричный ключ посредством ключа дешифрования, и направляет дешифрованный симметричный ключ в модуль (20) обращения; а модуль (20) обращения дешифрует документ, подлежащий дешифрованию, посредством симметричного ключа.

11. Способ по п. 1, отличающийся тем, что сертификатом является сертификат типа Х.509.

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

13. Система аутентификации пользователя (10) в объекте (16), содержащая модуль (20) обращения, выполненный с возможностью обнаружения обращения пользователя (10) в объект (16); терминал (12), выполненный с возможностью приема обращения, инициированного пользователем (10), с использованием модуля (20) обращения; модуль (24) аутентификации, выполненный с возможностью аутентификации пользователя (10); и мобильное устройство (14), выполненное с возможностью приема сетевого адреса модуля (24) аутентификации в сообщении аутентификации из модуля (20) обращения, отличающаяся тем, что дополнительно содержит модуль (26) очереди сообщений, соответствующий объекту (16), при этом сообщение аутентификации представляет собой сообщение типа очереди сообщений, передаваемое посредством модуля (26) очереди сообщений, а мобильное устройство (14) выполнено с возможностью передачи подписанного ключом пользователя (10) уведомления о получении в модуль (20) обращения после приема указанного сообщения типа очереди сообщений, причем мобильное устройство (14) находится в соединении с модулем (26) очереди сообщений;мобильное устройство (14) выполнено с возможностью проверки допустимости сертификата объекта модуля (24) аутентификации на основании сетевого адреса; модуль (24) аутентификации выполнен с возможностью проверки допустимости сертификата пользователя мобильного устройства (14); и если сертификат объекта и сертификат пользователя являются допустимыми, то пользователь (10) аутентифицируется системой в объекте (16) путем установления канала (114, 120, 122, 124) связи между мобильным устройством (14) и модулем (24) аутентификации, а если сертификат объекта или сертификат пользователя не является допустимым, то пользователь (10) получает в объекте (16) отказ в аутентификации.