Способы безопасного генерирования криптограмм

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

 

ПЕРЕКРЕСТНЫЕ ССЫЛКИ НА РОДСТВЕННЫЕ ЗАЯВКИ

[0001] Настоящая заявка не является предварительной и заявляет приоритет предварительной заявки США 62/044172, поданной 29 августа 2014 (номер дела патентного поверенного 79900-914352-1068US01). Все содержание вышеуказанной заявки настоящим включено с помощью ссылки для всех целей во всей полноте.

ПРЕДПОСЫЛКИ ИЗОБРЕТЕНИЯ

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

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

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

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

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

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

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

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

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

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

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

[0012] Удостоверяющие данные также могут содержать один или несколько дополнительных совместно используемых секретных ключей и/или ключей (таких как ключ ограниченного использования (LUK)), совместно используемых с компьютерами сервера (например, сервером предоставления и/или проверяющим подлинность сервером). Такие совместно используемые секретные ключи и/или ключи предпочтительно являются уникальными для конкретного пользовательского устройства или группы пользовательских устройств.

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

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

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

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

[0016] На фиг. 1 показана приведенная в качестве примера платежная система согласно некоторым вариантам осуществления.

[0017] На фиг. 2 показано приведенное в качестве примера пользовательское устройство согласно некоторым вариантам осуществления.

[0018] На фиг. 3 показан приведенный в качестве примера компьютер сервера согласно некоторым вариантам осуществления.

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

[0020] На фиг. 6-7 показан приведенный в качестве примера процесс или способ безопасной обработки сообщения с запросом предоставления от пользовательского устройства и предоставления сообщения с ответом предоставления на пользовательское устройство согласно некоторым вариантам осуществления.

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

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

[0023] На фиг. 10 показана схема информационных потоков приведенного в качестве примера процесса внесения в реестр согласно некоторым вариантам осуществления.

[0024] На фиг. 11 показана блок-схема приведенного в качестве примера процесса внесения в реестр согласно некоторым вариантам осуществления.

[0025] На фиг. 12 показан приведенный в качестве примера процесс или способ транзакции для проведения транзакции согласно некоторым вариантам осуществления.

[0026] На фиг. 13 показан приведенный в качестве примера процесс или способ транзакции для проведения транзакции согласно некоторым вариантам осуществления.

[0027] На фиг. 14 показана схема информационных потоков процесса транзакции согласно некоторым вариантам осуществления.

[0028] На фиг. 15 показана блок-схема процесса транзакции согласно некоторым вариантам осуществления.

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

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

[0031] На фиг. 18 показана блок-схема процесса обновления ключа согласно некоторым вариантам осуществления.

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

ТЕРМИНЫ

[0033] Перед обсуждением вариантов осуществления изобретения для понимания вариантов осуществления настоящего изобретения может быть полезным описание некоторых терминов.

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

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

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

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

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

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

[0040] «Криптографический объект nonce» может включать любое число, строку, последовательность битов или другое значение данных, предназначенное для использования совместно с одним сеансом связи. В некоторых случаях криптографический объект nonce может быть сгенерирован случайным или псевдослучайным образом. Например, криптографический объект nonce может представлять собой случайное число. Как правило, криптографический объект nonce имеет достаточную длину, чтобы сделать незначительной вероятность независимого генерирования одинакового значения объекта nonce несколько раз.

[0041] «Заблокированный ключ», например, «заблокированный открытый ключ», может включать ключ, который был искажен или иным образом изменен в сравнении с его изначальным значением путем сочетания с другим элементом данных, таким как криптографический объект nonce. Например, в криптографии на основе эллиптических кривых, для генерирования «заблокированного открытого ключа» открытый ключ может быть умножен на объект nonce. Аналогично, для генерирования «заблокированного закрытого ключа» закрытый ключ может быть умножен на объект nonce.

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

[0043] «Пара статических ключей» может включать открытый ключ (т. е. «статический открытый ключ») и закрытый ключ (т. е. «статический закрытый ключ»), сохраняемые в течение периода времени. Как правило, хотя и не обязательно, статический закрытый ключ может быть сохранен безопасным образом, например, в аппаратном модуле безопасности (HSM) или элементе безопасности (SE). Как правило, хотя и не обязательно, статический открытый ключ может быть связан с субъектом с помощью цифрового сертификата. «Пара статических ключей» может иметь любой подходящий формат, такой как ECC или RSA.

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

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

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

[0047] «Фактор идентификации» может включать любые данные или информацию, определенную из идентификационных данных и/или аутентификационных данных. Как правило, хотя и не обязательно, фактор идентификации может быть сгенерирован путем хеширования сочетания идентификационных данных и аутентификационных данных.

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

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

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

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

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

ПОДРОБНОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ

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

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

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

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

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

[0058] Приведенные выше примеры освещают только несколько преимуществ, обеспечиваемых вариантами осуществления изобретения.

СИСТЕМЫ

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

Платежная система

[0060] На фиг. 1 показана приведенная в качестве примера платежная система 100 согласно некоторым вариантам осуществления. Система содержит пользователя (не показан), который может управлять пользовательским устройством 101. Пользователь может использовать пользовательское устройство 101 для проведения платежных транзакций в связи с устройством 102 доступа. Как используется в данном документе, «пользовательское устройство» может включать настольный компьютер, портативный переносной компьютер, мобильный телефон, планшет, кредитную карту, дебетовую карту или любое подходящее вычислительное устройство. Как используется в данном документе, «устройство доступа» может включать любое вычислительное устройство, такое как торговый (POS) терминал или веб-сервер, подходящий для осуществления связи с пользовательским устройством. В некоторых вариантах осуществления устройство 102 доступа может прямо осуществлять связь с пользовательским устройством 101. В других вариантах осуществления устройство 102 доступа может осуществлять связь с пользовательским устройством 101 через интерфейсное устройство, такое как умные часы, умные очки или любое другое подходящее устройство. Устройство 102 доступа может быть подключено к компьютеру 103 продавца, который может быть подключен к компьютеру 104 эквайера. Компьютер 104 эквайера может быть подключен к компьютеру 106 эмитента через сеть 105 обработки платежей. Пользовательское устройство 101 может необязательно осуществлять связь с запоминающим устройством 107, которое может быть функционально соединено с пользовательским устройством 101. Запоминающее устройство 107 может содержать любой подходящий локальный или удаленный сервер хранения данных, систему или сервис, предоставляемый поставщиком услуг хранения данных, или содержаться в них. Поставщик услуг хранения данных может не быть тем же субъектом, который предоставляет устройства 101-106. Например, запоминающее устройство 107 может быть частью услуг по хранению данных на облаке, предоставляемых внешним поставщиком услуг хранения данных на облаке. Любые или все устройства 101-107 могут быть реализованы с помощью одного или нескольких вычислительных устройств, таких как компьютеры сервера.

[0061] Как использовано в данном документе, «эмитент» может, как правило, относиться к субъекту предпринимательства (например, банку), который содержит финансовые счета для пользователя и часто эмитирует или выдает пользователю пользовательское устройство 101, такое как кредитная или дебетовая карта, или мобильное устройство. «Продавец», как правило, представляет собой субъект, который вовлечен в транзакции и может продавать товары или услуги. «Эквайер», как правило, представляет собой субъект предпринимательства (например, коммерческий банк), который имеет коммерческую связь с конкретным продавцом или другим субъектом. Некоторые субъекты могут выполнять функции как эмитента, так и эквайера. Некоторые варианты осуществления могут охватывать такие заключенные в одном субъекте эмитенты и эквайеры. Каждый из субъектов может иметь одно или несколько вычислительных устройств (например, устройство 102 доступа, компьютер 103 продавца, компьютер 104 эквайера, сеть 105 обработки платежей и компьютер 106 эмитента), чтобы обеспечивать возможность осуществления связи или выполнять одну или несколько функций, описанных в данном документе.

[0062] Сеть 105 обработки платежей может содержать подсистемы, сети и операции обработки данных, используемые для поддержки и предоставления услуг органов сертификации, услуг авторизации, услуг файлов стоп-листов, услуг оценки транзакций и услуг клиринга и расчетов. Примером сети обработки платежей может служить VisaNet™. Сети обработки платежей, такие как VisaNet™, могут обрабатывать транзакции кредитных карт, транзакции дебетовых карт и другие типы коммерческих транзакций. VisaNet™, в частности, содержит систему VIP (визовые совместные платежи), которая обрабатывает запросы авторизации, и систему Base II, которая выполняет услуги клиринга и расчетов.

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

[0064] В некоторых платежных транзакциях пользователь приобретает товар или услугу у продавца с помощью пользовательского устройства 101. Пользовательское устройство 101 может взаимодействовать с устройством 102 доступа у продавца, связанного с компьютером 103 продавца. Например, пользователь может провести пользовательским устройством 101 по устройству считывания NFC в устройстве 102 доступа. Альтернативно, пользователь может указать платежные реквизиты продавцу по компьютерной сети, как, например, в онлайн-транзакции или транзакции электронной коммерции.

[0065] Сообщение с запросом авторизации для транзакции может быть сгенерировано устройством 102 доступа или компьютером 103 продавца и затем направлено на компьютер 104 эквайера. После приема сообщения с запросом авторизации компьютер 104 эквайера отправляет сообщение с запросом авторизации в сеть 105 обработки платежей. Сеть 105 обработки платежей затем направляет сообщение с запросом авторизации на соответствующий компьютер 106 эмитента, связанный с эмитентом, связанным с пользователем или пользовательским устройством 101.

[0066] «Сообщение с запросом авторизации» может представлять собой электронное сообщение, которое отправляют в сеть обработки платежей и/или эмитенту с целью запроса авторизации для транзакции. Сообщение с запросом авторизации согласно некоторым вариантам осуществления может соответствовать ISO 8583, который является стандартом для систем, которые обмениваются информацией электронных транзакций, связанной с платежом, сделанным пользователем с помощью платежного устройства или расчетного счета. Сообщение с запросом авторизации может содержать идентификатор счета эмитента, который может быть связан с платежным устройством или расчетным счетом. Сообщение с запросом авторизации также может содержать дополнительные элементы данных, соответствующие «идентификационной информации», включая, только в качестве примера: служебный код, CVV (код проверки карты), dCVV (динамический код проверки карты), дату завершения срока действия и т. п. Сообщение с запросом авторизации также может содержать «информацию транзакции», такую как любая информация, связанная с текущей транзакцией, такую как сумма транзакции, идентификатор продавца, местоположение продавца, и т. п., а также любую другую информацию, которая может быть использована при определении, следует ли идентифицировать и/или авторизовать транзакцию. Сообщение с запросом авторизации также может содержать другую информацию, такую как информация, которая идентифицирует устройство доступа, которое сгенерировало сообщение с запросом авторизации, информация о местоположении устройства доступа и т. п.

[0067] После того как компьютер 106 эмитента принимает сообщение с запросом авторизации, компьютер 106 эмитента отправляет сообщение с ответом авторизации обратно в сеть 105 обработки платежей, чтобы указать, авторизована (или не авторизована) текущая транзакция. Сеть 105 обработки платежей затем направляет сообщение с ответом авторизации обратно на компьютер 104 эквайера. В некоторых вариантах осуществления сеть 105 обработки платежей может отклонить транзакцию, даже если компьютер 106 эмитента авторизовал транзакцию, например, в зависимости от величины оценки риска потерь от мошенничества. Компьютер 104 эквайера затем отправляет сообщение с ответом обратно на компьютер 103 продавца.

[0068] «Сообщение с ответом авторизации» может представлять собой ответ в электронном сообщении на сообщение с запросом авторизации, сгенерированное компьютером 106 эмитента и/или сетью 105 обработки платежей. Сообщение с ответом авторизации может содержать, только в качестве примера, один или несколько из следующих индикаторов состояния: «одобрение» -транзакция была одобрена; «отклонение» -транзакция не была одобрена; или «вызов центра» -ответ, требующий больше информации, при этом продавец должен позвонить по бесплатному телефонному номеру для авторизации. Сообщение с ответом авторизации также может содержать код авторизации, который может представлять собой код, который эмитент возвращает в ответ на сообщение с запросом авторизации в электронном сообщении (или прямо, или через сеть 105 обработки платежей) на компьютер 103 продавца, которое обозначает подтверждение транзакции. Код может служить подтверждением авторизации. Как указано выше, в некоторых вариантах осуществления сеть 105 обработки платежей может генерировать или направлять сообщение с ответом авторизации продавцу, как правило, через компьютер 104 эквайера.

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

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

Пользовательское устройство

[0071] На фиг. 2 показано приведенное в качестве примера пользовательское устройство 200 согласно некоторым вариантам осуществления. Например, пользовательское устройство 200 может содержать пользовательское устройство 101, представленное на фиг. 1, или содержаться в нем. Примеры пользовательских устройств 200 могут включать мобильные телефоны, планшеты, настольные и портативные переносные компьютеры, носимые устройства (например, умные часы, фитнес-браслеты, браслеты на лодыжку, кольца, серьги и т. п.) или любые другие вычислительные устройства, выполненные с возможностью приема, хранения и передачи данных. Пользовательское устройство 200 может быть выполнено с возможностью осуществления связи прямо или косвенно с компьютером 300 сервера для осуществления способов, описанных в данном документе. Пользовательское устройство 200 может содержать процессор 201, с возможностью связи подключенный к сетевому интерфейсу 202, память 203, машиночитаемый носитель 210 и необязательно элемент 204 безопасности.

[0072] Процессор 201 может содержать один или несколько центральных процессоров (ЦП), каждый из которых может содержать по меньшей мере одно процессорное ядро, функционирующее для выполнения программных компонентов для выполнения запросов, генерируемых пользователем и/или системой. ЦП может представлять собой микропроцессор, такой как Athlon, Duron и/или Opteron от AMD; PowerPC от IBM и/или Motorola; процессор архитектуры Cell от IBM и Sony; Celeron, Itanium, Pentium, Xeon и/или XScale от Intel; и/или подобный процессор (процессоры). ЦП взаимодействует с памятью посредством прохождения сигналов через проводящие каналы для выполнения хранимого программного кода сигналов согласно обычным способам обработки данных. В некоторых случаях процессор 201 может содержать несколько ЦП, соединенных по сети, как, например, в распределенной или кластерной вычислительной системе.

[0073] Сетевой интерфейс 202 может быть выполнен с возможностью обеспечения вычислительному устройству 200 возможности осуществления связи с другими субъектами, такими как устройства 101-107, другими вычислительными устройствами, и т. п., с помощью одной или нескольких сетей связи. Сетевые интерфейсы могут принимать, осуществлять связь и/или подключаться к сети связи. Сетевые интерфейсы могут применять такие протоколы подключения как, но без ограничения, прямое соединение, Ethernet (толстый кабель, тонкий кабель, витая пара 10/100/1000 Base T и/или т. п.), кольцевая сеть с передачей маркера (Token Ring), беспроводное соединение, такое как IEEE 802.11a-x, и/или т. п. Сеть связи может представлять собой любую из и/или сочетание следующего: прямое соединение; Интернет; локальная вычислительная сеть (LAN); городская вычислительная сеть (MAN); безопасное обычное соединение; региональная вычислительная сеть (WAN); беспроводная сеть (например, применяющая, но без ограничения, такие протоколы, как протокол для беспроводной передачи данных (WAP), I-mode и/или т. п.); и/или т. п.

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

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

[0076] Машиночитаемый носитель 210 может иметь форму памяти (например, флеш, ПЗУ, и т. п.) и может содержать код, выполняемый процессором 201 для осуществления способов, описанных в данном документе. Машиночитаемый носитель 210 может содержать модуль 211 аутентификации, модуль 212 шифрования и модуль 213 приложений. В разных вариантах осуществления такие модули могут быть выполнены с возможностью выполнения вместе или по отдельности некоторых или всех из способов 400, 800, 1100, 1200, 1500, 1600, 1800, представленных на фиг. 4-5, 8, 11, 12, 15 и 18, соответственно.

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

[0078] Модуль 212 шифрования может содержать любую программу, программное обеспечение или другой код, подходящий для выполнения операций, связанных с шифрованием и/или расшифровкой. Например, модуль шифрования может быть выполнен с возможностью генерирования совместно используемого секретного ключа, например, с помощью протокола согласования ключей, такого как протокол Диффи-Хеллмана. Модуль 212 шифрования может быть дополнительно выполнен с возможностью формирования ключа сеанса из совместно используемого секретного ключа, например, с помощью функции формирования ключа (KDF). В некоторых вариантах осуществления модуль 212 шифрования может быть выполнен с возможностью хранения одного или нескольких статических ключей, таких как статический закрытый ключ пользовательского устройства или статический закрытый ключ компьютера сервера. В некоторых вариантах осуществления модуль 212 шифрования может быть реализован с помощью любого сочетания программного (такого как хост-эмуляция карты, или HCE) и аппаратного (такого как аппаратный модуль безопасности, или HSM) обеспечения.

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

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

Компьютер сервера

[0081] На фиг. 3 показан приведенный в качестве примера компьютер 300 сервера согласно некоторым вариантам осуществления. Например, компьютер 300 сервера может содержать любое из устройств 102-106, представленных на фиг. 1, или содержаться в нем. Примеры компьютеров 300 сервера могут включать мобильные телефоны, планшеты, настольные и портативные переносные компьютеры, крупные универсальные компьютеры или любое другое вычислительное устройство, подходящее для приема, хранения и передачи данных. Компьютер 300 сервера может быть выполнен с возможностью осуществления связи прямо или косвенно с пользовательским устройством 200 для осуществления способов, описанных в данном документе. Компьютер 300 сервера может содержать процессор 301, с возможностью связи подключенный к сетевому интерфейсу 302, память 303, машиночитаемый носитель 310 и необязательно элемент 304 безопасности.

[0082] Процессор 301, сетевой интерфейс 302, память 303 могут быть подобны процессору 201, сетевому интерфейсу 202 и памяти 203 пользовательского устройства 200. Машиночитаемый носитель 310 может иметь форму памяти (например, флеш, ПЗУ, и т. п.) и может содержать код, выполняемый процессором 301 для осуществления способов, описанных в данном документе. Машиночитаемый носитель 310 может содержать модуль 311 аутентификации, модуль 312 шифрования и модуль 313 приложений. В разных вариантах осуществления такие модули могут быть выполнены с возможностью выполнения вместе или по отдельности некоторых или всех из способов 600, 900, 1100, 1300, 1500, 1700, 1800, представленных на фиг. 6-7, 9, 11, 13, 15, 17 и 18, соответственно.

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

[0084] Модуль 312 шифрования может содержать любую программу, программное обеспечение или другой код, подходящий для выполнения операций, связанных с шифрованием и/или расшифровкой. Например, модуль шифрования может быть выполнен с возможностью генерирования совместно используемого секретного ключа, например, с помощью протокола согласования ключей, такого как протокол Диффи-Хеллмана. Модуль 312 шифрования может быть дополнительно выполнен с возможностью формирования ключа сеанса из совместно используемого секретного ключа, например, с помощью функции формирования ключа (KDF). В некоторых вариантах осуществления модуль 312 шифрования может быть выполнен с возможностью хранения одного или нескольких статических ключей, таких как статический закрытый ключ пользовательского устройства или статический закрытый ключ компьютера сервера. В некоторых вариантах осуществления модуль 312 шифрования может быть реализован с помощью любого сочетания программного (такого как хост-эмуляция карты, или HCE) и аппаратного (такого как аппаратный модуль безопасности, или HSM) обеспечения.

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

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

[0087] Хотя использован общий термин «компьютер сервера», в некоторых вариантах осуществления может быть предусмотрено осуществление разными компьютерами сервера разных признаков изобретения. Например, сервер предоставления может быть выполнен с возможностью создания совместно используемого секретного ключа (ключей) посредством пользовательского устройства и предоставления удостоверяющих данных, включая маркер, параметры формирования ключа, параметры обновления, параметры формирования криптограммы, параметры транзакции и любые другие соответствующие данные на пользовательское устройство. Сервер регистрации может быть выполнен с возможностью предоставления регистрационных данных на пользовательское устройство, принятия криптограммы регистрации от пользовательского устройства и проверки подлинности криптограммы регистрации с помощью регистрационных данных, предоставленных пользовательским устройством. Проверяющий подлинность сервер может быть выполнен с возможностью проверки подлинности криптограмм транзакции, предоставленных пользовательским устройством, с помощью обновленного совместно используемого секретного ключа, который определяют на основе предыдущего совместно используемого секретного ключа. Сервер обновления может быть выполнен с возможностью создания нового совместно используемого секретного ключа, который может быть установлен между пользователем и компьютером сервера. Кроме того, сервер обновления может быть выполнен с возможностью предоставления новых параметров (например, новых параметров формирования ключа, новых параметров формирования криптограммы и/или новых параметров обновления), которые могут быть поданы на пользовательское устройство для использования для генерирования криптограмм и/или криптограммных ключей.

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

СПОСОБЫ ПРЕДОСТАВЛЕНИЯ УДОСТОВЕРЯЮЩИХ ДАННЫХ

[0089] В вариантах осуществления могут использоваться системы и устройства, описанные выше, для предоставления данных, таких как удостоверяющие данные, с компьютера сервера на пользовательское устройство. На фиг. 4-7 показаны некоторые примеры таких способов. В некоторых вариантах осуществления пользовательское устройство может включать пользовательское устройство 101 или 200, представленное на фиг. 1 и 2, соответственно. Компьютер сервера может включать устройство 102, 103, 104, 105, 106 или 300, представленное на фиг. 1 и 3, соответственно. В некоторых вариантах осуществления компьютер сервера может включать компьютер сервера предоставления.

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

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

[0092] В разных вариантах осуществления любой или оба из первого компьютера и компьютера сервера могут быть частью любого из устройств, сетей или компьютеров 101-106. Например, в некоторых вариантах осуществления пользовательское устройство может представлять собой пользовательское устройство 101, а компьютер сервера может представлять собой устройство 102 доступа, компьютер 103 продавца, компьютер 104 эквайера, компьютер 105 сети обработки платежей, компьютер 106 эмитента или любое другое подходящее устройство. В таких вариантах осуществления, когда пользователь проводит транзакцию, пользовательское устройство осуществляет связь с компьютером сервера.

A. Пользовательское устройство

[0093] На фиг. 4-5 показан приведенный в качестве примера процесс или способ 400 безопасного предоставления (например, удостоверяющих данных) с компьютера сервера согласно некоторым вариантам осуществления. Аспекты процесса 400 могут быть выполнены пользовательским устройством, таким как пользовательское устройство 101 или 200. Альтернативно или дополнительно, аспекты процесса 400 могут быть выполнены любыми другими подходящими субъектами. Некоторые или все аспекты процесса 400 (или любых других процессов, описанных в данном документе, или их вариантов и/или сочетаний) могут быть выполнены под управлением одного или нескольких компьютеров/систем управления, снабженных выполняемыми командами, и могут быть реализованы в виде кода (например, выполняемых команд, одной или нескольких компьютерных программ или одного или нескольких приложений), выполняемого вместе на одном или нескольких процессорах, аппаратным обеспечением или их сочетанием. Код может храниться в машиночитаемом носителе данных, например, в форме компьютерной программы, содержащей множество команд, выполняемых одним или несколькими процессорами. Машиночитаемый носитель данных может быть постоянным. Порядок, в котором описаны операции, не предназначен для рассмотрения в качестве ограничения, и для осуществления процессов любое количество описанных операций можно сочетать в любом порядке и/или параллельно.

[0094] На этапе 401 определяют пару кратковременных ключей. «Пара кратковременных ключей» может включать открытый ключ (т. е. «кратковременный открытый ключ») и закрытый ключ (т. е. «кратковременный закрытый ключ»), сгенерированные для использования с одной транзакцией или другим сеансом связи. Пара кратковременных ключей может иметь любой подходящий формат, такой как ECC или RSA. Как правило, пара кратковременных ключей может быть удалена сразу после завершения сеанса связи, использующего кратковременный ключ, или когда с помощью пары кратковременных ключей были сгенерированы один или несколько совместно используемых секретных ключей. Такое удаление пар кратковременных ключей может уменьшить риски нарушения безопасности.

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

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

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

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

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

[0100] Ключ сеанса может иметь любой подходящий формат (например, AES, DES, Blowfish и т. п.) любую подходящую длину и быть сгенерирован с помощью любой подходящей функции формирования ключа (KDF). Например, в одном варианте осуществления ключ сеанса может быть сгенерирован с помощью алгоритма функции формирования ключа на основе пароля 2 (PBKDF2). В некоторых вариантах осуществления в качестве дополнительных входных данных для функции формирования ключа могут быть использованы другие данные, такие как идентификатор пользовательского устройства.

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

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

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

[0104] Переходя к этапу 408, представленному на фиг. 5, с компьютера сервера принимают сообщение с ответом предоставления, содержащее заблокированный статический открытый ключ компьютера сервера и зашифрованные данные ответа. Как правило, заблокированный статический открытый ключ компьютера сервера может представлять собой заблокированную форму статического открытого ключа компьютера сервера, используемого на этапе 404 для генерирования первого совместно используемого секретного ключа. В таких вариантах осуществления первый совместно используемый секретный ключ отличается от второго совместно используемого секретного ключа, который обсуждается ниже. В некоторых других вариантах осуществления статический открытый ключ компьютера сервера, принятый от компьютера сервера, может быть не заблокирован. В таких вариантах осуществления второй совместно используемый секретный ключ по существу является таким же, что и первый совместно используемый секретный ключ. Когда статический открытый ключ компьютера сервера не заблокирован, криптографический объект nonce может быть предоставлен как часть данных ответа и использован для вычисления криптограмм. Например, криптографический объект nonce из сервера (энтропия) может быть использован или сохранен для дальнейшего формирования, или второй криптографический объект nonce может быть предоставлен как часть параметров формирования. Важно, что энтропия с сервера используется при вычислении криптограмм (например, криптограмм платежных транзакций).

[0105] На этапе 409 с помощью кратковременного закрытого ключа и статического открытого ключа сервера определяют второй совместно используемый секретный ключ. В некоторых случаях второй совместно используемый секретный ключ может быть назван совместно используемым секретным ключом ответа, поскольку его используют для (например, шифрования и/или расшифровки) сообщения с ответом, как обсуждается ниже. В некоторых вариантах осуществления заблокированный статический открытый ключ компьютера сервера принимают от компьютера сервера на этапе 408. В некоторых других вариантах осуществления заблокированный ключ формируют из статического открытого ключа сервера на пользовательском устройстве. Заблокированный ключ может быть сформирован с помощью криптографического объекта nonce, который может быть предоставлен как часть сообщения с ответом предоставления. Криптографический объект nonce может представлять собой случайное число. Криптографический объект nonce также может быть использован для проверки сертификата компьютера сервера, как обсуждается в другом месте.

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

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

[0108] На этапе 411 зашифрованные данные ответа расшифровывают с помощью второго ключа сеанса для получения криптографического объекта nonce, цепочки сертификатов компьютера сервера и полезных данных. Цепочка сертификатов компьютера сервера может включать цепочку из одного или нескольких подписанных сертификатов от корневого сертификата ОС до сертификата компьютера сервера, благодаря чему цепочка устанавливает подлинность сертификата компьютера сервера. Полезные данные могут содержать любые подходящие данные. Например, полезные данные могут содержать неудостоверяющую информацию, такую как подтверждение транзакции, баланс счета пользователя и т. п., и удостоверяющие данные, такие как удостоверяющие данные платежа. Полезные данные или удостоверяющие данные платежа могут содержать одно или несколько из: PAN или маркер (например, заменитель PAN), ключ ограниченного использования (LUK), который может быть использован для проведения будущих транзакций, и другие параметры формирования ключа, которые могут быть использованы для формирования криптограммных ключей, параметры обновления, параметры транзакции и т. п. Некоторые или все части данных ответа могут быть зашифрованы с помощью одного или нескольких ключей шифрования.

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

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

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

[0112] Параметры формирования ключа, параметры формирования криптограммы и/или параметры обновления могут содержать LUK, указание, какие параметры транзакции из данной транзакции использовать, код для выполнения формирования (или идентификатор процедуры, которую надо использовать) и/или другую информацию, связанную с этими параметрами. В некоторых вариантах осуществления параметры формирования ключа, параметры формирования криптограммы и/или параметры обновления могут содержать «фиктивные» или неверные параметры с целью искажения. Код может представлять собой код персонализированного способа формирования, в том смысле, что он является уникальным для устройства или группы устройств, и может быть назначен случайным образом. Код может быть подписан сервером или другим поставщиком, так что пользовательское устройство может аутентифицировать код. В некоторых вариантах осуществления код перед подписыванием искажают, таким образом затрудняя взломщику понимание, обход и/или обратную разработку кода.

[0113] На этапе 412 проверяется подлинность цепочки сертификатов компьютера сервера. Цепочка сертификатов компьютера сервера может быть проверена на подлинность с помощью любого подходящего онлайн или офлайн способа. Например, для каждого из одного или нескольких сертификатов в цепочке цифровая подпись сертификата может быть проверена на подлинность с помощью известного доверенного открытого ключа (например, открытого ключа органа сертификации, или открытого ключа субъекта, соответствующим образом авторизованного ОС). Например, в некоторых вариантах осуществления для проверки подлинности сертификата может быть использован алгоритм цифровой подписи, такой как алгоритм цифровой подписи на эллиптических кривых (ECDSA). В некоторых вариантах осуществления сертификат компьютера сервера может быть проверен с помощью криптографического объекта nonce, который предоставлен как часть сообщения с ответом предоставления (например, как часть удостоверяющих данных).

[0114] На этапе 413 заблокированный статический открытый ключ компьютера сервера проверяют с помощью сертификата компьютера сервера и криптографического объекта nonce. Проверка заблокированного статического открытого ключа компьютера сервера может включать получение подтверждения, что заблокированный статический открытый ключ компьютера сервера соответствует ожидаемому значению. Например, в некоторых случаях второй заблокированный статический открытый ключ компьютера сервера может быть сгенерирован с помощью статического открытого ключа компьютера сервера, включенного в сертификат компьютера сервера, и криптографического объекта nonce, расшифрованного на этапе 411. Второй заблокированный статический открытый ключ компьютера сервера затем может быть сравнен с заблокированным статическим открытым ключом компьютера сервера, принятым на этапе 408, чтобы убедиться, что ключи соответствуют. Альтернативно, в некоторых случаях заблокированный статический открытый ключ компьютера сервера, принятый на этапе 408, может быть проверен путем его сравнения с хранящимся заблокированным статическим открытым ключом компьютера сервера. Если ключи соответствуют, компьютер сервера может быть аутентифицирован. Иначе, аутентификация может потерпеть неудачу.

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

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

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

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

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

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

B. Компьютер сервера

[0121] На фиг. 6-7 показан приведенный в качестве примера процесс или способ 600 безопасного предоставления данных (например, удостоверяющих данных) на пользовательское устройство согласно некоторым вариантам осуществления. Аспекты процесса 600 могут быть выполнены компьютером сервера, таким как серверное устройство или компьютер 102, 103, 104, 105, 106 или 300. Например, процесс 600 может быть выполнен сервером предоставления. Альтернативно или дополнительно, аспекты процесса 600 могут быть выполнены любыми другими подходящими субъектами.

[0122] Как правило, до выполнения способа 600, компьютер сервера имеет пару статических ключей компьютера сервера. Пара статических ключей компьютера сервера может содержать открытый ключ (т. е. «статический открытый ключ компьютера сервера») и закрытый ключ (т. е. «статический закрытый ключ компьютера сервера»). Компьютер сервера также может содержать «сертификат компьютера сервера», содержащий статический открытый ключ компьютера сервера. Сертификат компьютера сервера может быть подписан органом сертификации, таким как сеть 105 обработки платежей или компьютер 106 эмитента.

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

[0124] На этапе 602 с помощью комбинированного кратковременного открытого ключа, принятого на этапе 601, и статического закрытого ключа компьютера сервера генерируют первый (запросный) совместно используемый секретный ключ. Совместно используемый секретный ключ может быть сгенерирован из комбинированного кратковременного открытого ключа и статического закрытого ключа компьютера сервера с помощью любого подходящего способа, например, ECDH.

[0125] На этапе 603 с помощью первого совместно используемого секретного ключа и первых вспомогательных данных генерируют первый ключ сеанса. Первые вспомогательные данные могут содержать любые другие данные, используемые для генерирования первого ключа сеанса. Как правило, те же данные, которые использованы для генерирования первого ключа сеанса на пользовательском устройстве (например, в соответствии с этапом 405 способа 400), могут быть использованы и на этапе 603.

[0126] На этапе 604 зашифрованные данные запроса расшифровывают с помощью первого ключа сеанса для получения данных запроса, содержащих кратковременный открытый ключ, идентификатор пользовательского устройства и идентификационные данные. Кратковременный открытый ключ может соответствовать комбинированному кратковременному открытому ключу, принятому на этапе 601. Идентификатор пользовательского устройства может содержать любые данные, подходящие для идентификации пользовательского устройства. Идентификационные данные могут содержать любые данные или информацию, связанные с пользователем или пользовательским устройством. Примеры идентификационных данных могут включать имя пользователя, связанное с пользовательским устройством, организацию, связанную с пользовательским устройством, платежную информацию, такую как номер основного счета (PAN) или маркер, связанный с пользовательским устройством, дату завершения срока действия, связанную с PAN или маркером, сертификат, связанный с пользовательским устройством, IMEI или серийный номер пользовательского устройства, и т. п.

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

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

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

[0130] На этапе 608 комбинированный кратковременный открытый ключ проверяют с помощью кратковременного открытого ключа и фактора идентификации. Проверка комбинированного кратковременного открытого ключа может включать подтверждение того, что комбинированный кратковременный открытый ключ соответствует ожидаемому значению. Например, в некоторых случаях второй комбинированный кратковременный открытый ключ может быть сгенерирован с помощью кратковременного открытого ключа, полученного на этапе 604, и фактора идентификации, определенного на этапе 607. Второй комбинированный кратковременный открытый ключ затем может быть сравнен с комбинированным кратковременным открытым ключом, принятым на этапе 601, чтобы убедиться, что ключи соответствуют. Если ключи соответствуют, пользовательское устройство может быть аутентифицировано. Иначе, аутентификация может потерпеть неудачу.

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

[0132] Переходя к этапу 609, представленному на фиг. 7, генерируют криптографический объект nonce. Криптографический объект nonce может представлять собой случайное или псевдослучайное значение данных, сгенерированное с помощью любого подходящего способа.

[0133] На этапе 610 статический открытый ключ компьютера сервера и статический закрытый ключ компьютера сервера блокируют с помощью криптографического объекта nonce и фактора идентификации. В результате могут быть определены заблокированный статический открытый ключ компьютера сервера и/или заблокированный статический закрытый ключ компьютера сервера. Заблокированный ключ может включать ключ, который был искажен или иным образом изменен в сравнении с его изначальным значением путем сочетания с одним или несколькими другими элементами данных. Например, комбинированный кратковременный открытый ключ может представлять собой сочетание (например, точечное умножение) кратковременного открытого ключа, криптографического объекта nonce и фактора идентификации. Аналогично, комбинированный кратковременный закрытый ключ может представлять собой сочетание кратковременного закрытого ключа, криптографического объекта nonce и фактора идентификации.

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

[0135] На этапе 612 с помощью второго совместно используемого секретного ключа и вторых вспомогательных данных генерируют второй ключ сеанса. Вторые вспомогательные данные могут содержать любые другие данные, используемые для генерирования второго ключа сеанса. Как правило, те же данные, которые использованы для генерирования второго ключа сеанса на пользовательском устройстве (например, в соответствии с этапом 410 способа 400), могут быть использованы и на этапе 612.

[0136] На этапе 613 криптографический объект nonce, цепочка сертификатов компьютера сервера и другие удостоверяющие данные полезных данных шифруют с помощью второго ключа сеанса для генерирования зашифрованных данных ответа. Цепочка сертификатов компьютера сервера может включать цепочку из одного или нескольких подписанных сертификатов от корневого сертификата ОС до сертификата компьютера сервера, благодаря чему цепочка устанавливает подлинность сертификата компьютера сервера. Полезные данные могут содержать любые подходящие данные. Например, полезные данные могут содержать подтверждение транзакции, баланс счета пользователя, ключ ограниченного использования (LUK), который может быть использован для проведения будущих транзакций, и т. п. Полезные данные также могут содержать параметры формирования ключа, параметры формирования криптограммы, параметры обновления. Параметры формирования ключа, параметры формирования криптограммы и/или параметры обновления могут содержать LUK, указание, какие параметры транзакции из данной транзакции использовать, код для выполнения формирования (или идентификатор процедуры формирования, которую надо использовать) и/или другую информацию, связанную с этими параметрами. Код может представлять собой код персонализированного способа формирования, в том смысле, что он является уникальным для устройства или группы устройств, и может быть назначен случайным образом. Код может быть подписан сервером или другим поставщиком, так что пользовательское устройство может аутентифицировать код.

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

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

СПОСОБЫ ВНЕСЕНИЯ В РЕЕСТР

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

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

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

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

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

A. Пользовательское устройство

[0144] На фиг. 8 показан приведенный в качестве примера процесс или способ 800 внесения в реестр для предоставления пользовательскому устройству (например, пользовательскому устройству 101) ключа ограниченного использования, сгенерированного компьютером сервера (например, компьютером 105 сети обработки платежей), согласно некоторым вариантам осуществления. Аспекты процесса 800 могут быть выполнены пользовательским устройством 101 или 200, представленным на фиг. 1 и 2, соответственно. Компьютер сервера может содержать сервер предоставления и/или сервер регистрации.

[0145] На этапе 801 могут быть выполнены этапы 401-413 способа 400. В частности, пользовательское устройство может определять пару кратковременных ключей, содержащую кратковременный открытый ключ и кратковременный закрытый ключ. Пользовательское устройство может формировать первый ключ сеанса с помощью кратковременного закрытого ключа и открытого ключа компьютера сервера, и использовать первый ключ сеанса для шифрования фактора аутентификации (такого как удостоверяющие данные пользователя). Пользовательское устройство затем может отправлять сообщение с запросом предоставления, содержащее зашифрованный фактор аутентификации и кратковременный открытый ключ, на компьютер сервера. Сообщение с запросом предоставления также может функционировать как сообщение с запросом LUK. Сообщение с ответом предоставления/LUK может быть принято в ответ от компьютера сервера. Сообщение с ответом может содержать заблокированный открытый ключ компьютера сервера и зашифрованные данные ответа. Пользовательское устройство может генерировать второй совместно используемый секретный ключ с помощью кратковременного закрытого ключа и заблокированного открытого ключа компьютера сервера. Пользовательское устройство также может генерировать второй ключ сеанса с помощью второго совместно используемого секретного ключа и вторых вспомогательных данных, таких как идентификатор компьютера сервера, идентификатор пользовательского устройства и/или усеченный кратковременный открытый ключ. Зашифрованные данные ответа могут быть расшифрованы с помощью второго ключа сеанса для получения криптографического объекта nonce, цепочки сертификатов компьютера сервера и полезных данных. Цепочка сертификатов компьютера сервера и заблокированный открытый ключ компьютера сервера могут быть проверены или может быть определена их подлинность. Дополнительное описание этих этапов может быть найдено со ссылкой на соответствующие этапы способа 400.

[0146] На этапе 802 из удостоверяющих данных могут быть получены параметры формирования ключа. Параметры формирования ключа могут необязательно содержать ключ ограниченного использования (LUK). Как обсуждалось на этапе 411 способа 400, данные ответа с компьютера сервера могут содержать полезные данные, зашифрованные с помощью второго ключа сеанса, сформированного из второго совместно используемого секретного ключа. Полезные данные могут быть извлечены путем расшифровки данных ответа с помощью второго ключа сеанса, сформированного ранее из второго секретного ключа. Полезные данные могут содержать, среди других данных, удостоверяющие данные, которые могут содержать маркер, параметры формирования ключа, параметры обновления, параметры формирования криптограммы и т. п.

[0147] На этапе 808 регистрационные данные (например, одноразовый пароль (OTP)) могут быть приняты, например, от компьютера сервера. Компьютер сервера может представлять собой сервер регистрации, который может или не может быть таким же, что и сервер предоставления, описанный выше. Регистрационные данные могут быть переданы на пользовательское устройство с помощью отдельного канала связи по сравнению с каналом связи, используемым для передачи сообщений с запросом/ответом предоставления. Например, регистрационные данные могут быть переданы посредством SMS, электронного письма, телефонного вызова, онлайн-чата, факсимильного сообщения, почтовой связи и т. п., и введены пользователем вручную в пользовательское устройство. В некоторых других вариантах осуществления регистрационные данные могут быть предоставлены по тому же каналу связи, что и сообщения с запросом/ответом предоставления. В таких вариантах осуществления регистрационные данные могут быть предоставлены в сообщении с ответом предоставления или в другом сообщении.

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

[0149] На этапе 810 с помощью второго (ответного) совместно используемого секретного ключа и/или параметров формирования ключа может быть сгенерирован криптограммный ключ. В некоторых вариантах осуществления параметры формирования ключа могут необязательно содержать ключ ограниченного использования (LUK). Второй (ответный) совместно используемый секретный ключ может быть сгенерирован, например, на этапе 409 процесса предоставления, представленного на фиг. 5. Криптограммный ключ может быть сгенерирован с помощью некоторых или всех из второго совместно используемого секретного ключа, LUK и/или параметров формирования ключа. Например, криптограммный ключ может быть сгенерирован с помощью лишь одного LUK, одного второго совместно используемого секретного ключа (например, с помощью второго ключа сеанса, сформированного из второго совместно используемого секретного ключа) или одних параметров формирования ключа. Например, криптограммный ключ может представлять собой LUK или второй ключ сеанса. В некоторых других вариантах осуществления криптограммный ключ может быть сгенерирован с помощью LUK и второго совместно используемого секретного ключа, LUK и параметров формирования ключа, или второго совместно используемого секретного ключа и параметров формирования ключа. К примеру, криптограммный ключ может быть сгенерирован с помощью сочетания LUK и второго ключа сеанса. Еще в некоторых других вариантах осуществления криптограммный ключ может быть сгенерирован с помощью второго совместно используемого секретного ключа, LUK и параметров формирования ключа. LUK можно рассматривать как параметр формирования.

[0150] В некоторых вариантах осуществления перечень алгоритмов (например, алгоритмов или функций формирования ключа) и параметров (например, параметров формирования ключа и/или параметров обновления), обсуждаемых в данном документе, может быть уникальным для конкретного устройства или конкретной группы устройств для того, чтобы предотвратить обратную разработку. Изменение от устройства к устройству может быть основано на комплекте разработки программного обеспечения (SDK), установленном на устройстве. В некоторых вариантах осуществления точный алгоритм и/или параметры, используемые для формирования конкретного ключа или совместно используемого секретного ключа, могут быть определены с помощью битовой карты, хранящейся на устройстве. Интерпретация битовой карты и отображение битовой карты на фактический перечень алгоритмов и/или параметров может изменяться зависящим от устройства SDK. Например, на одном устройстве перечень хранимых алгоритмов может иметь вид {alg1, alg2,..., alg8}, тогда как на другом устройстве список хранимых алгоритмов может иметь вид {alg3, alg5, …., alg1}. Аналогично, перечни параметров формирования ключа и/или параметров обновления также могут быть сохранены по-разному на разных устройствах. В некоторых вариантах осуществления алгоритмы и/или параметры могут быть внесены в перечень случайным образом на некоторых или всех устройствах. Битовая карта может указывать на правильный индекс в перечне алгоритмов и/или параметров, который необходимо использовать для фактического генерирования ключа. В некоторых вариантах осуществления данные ответа, предоставляемые компьютером сервера, могут содержать битовую карту, которая указывает на правильные алгоритмы и/или параметры, которые необходимо использовать пользовательскому устройству для генерирования ключей и/или совместно используемых секретных ключей. В некоторых случаях битовая карта, предоставленная компьютером сервера, может быть сгенерирована специально для данного пользовательского устройства на основе порядка, в котором алгоритмы и/или параметры хранятся на пользовательском устройстве.

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

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

[0153] На этапе 812 принятые регистрационные данные (например, OTP), могут быть зашифрованы с помощью криптограммного ключа для генерирования криптограммы регистрации (RC). Дополнительно или альтернативно, криптограмма регистрации может быть сгенерирована с помощью других данных, таких как идентификационные данные, аутентификационные данные, другая информация, извлеченная из удостоверяющих данных и/или сообщения с ответом, и т. п. В одном примере криптограмму регистрации генерируют путем шифрования как OTP, так и идентификатора элемента безопасности пользовательского устройства (например, ID модуля идентификации абонента (SIM)). В некоторых вариантах осуществления ключ ограниченного использования (LUK) принимают из удостоверяющих данных, полученных ранее (например, на этапе 408 способа 400). LUK может быть использован для генерирования криптограммного ключа. В некоторых вариантах осуществления генерирование криптограммного ключа также использует параметры формирования ключа, содержащиеся в удостоверяющих данных.

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

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

[0156] На этапе 817 может быть выполнен этап 414 способа 400. А именно, удостоверяющие данные могут быть использованы для проведения платежных транзакций. Например, платежный маркер, LUK и/или параметры формирования ключа, содержащиеся в удостоверяющих данных, могут быть использованы для генерирования прямо или косвенно криптограмм транзакции, используемых для аутентификации будущих транзакций, как представлено на фиг. 12-15.

Компьютер сервера

[0157] На фиг. 9 показан приведенный в качестве примера процесс или способ 900 внесения в реестр для предоставления пользовательскому устройству (например, пользовательскому устройству 101) закрытых данных, таких как ключ ограниченного использования, сгенерированных компьютером сервера (например, компьютером 105 сети обработки платежей), согласно некоторым вариантам осуществления. Аспекты процесса 900 могут быть выполнены любым из серверных устройств 102-106 или 300, представленными на фиг. 1 и 3, соответственно. Например, процесс 900 может быть выполнен сервером предоставления и/или сервером регистрации, описанными в данном документе. В одном варианте осуществления этапы 901-911 выполняет сервер предоставления, а этапы 912-916 выполняет сервер регистрации. В одном варианте осуществления сервер предоставления является сервером регистрации.

[0158] На этапе 901 могут быть выполнены этапы 601-612 способа 600. В частности, от пользовательского устройства может быть принято сообщение с запросом предоставления, содержащее комбинированный кратковременный открытый ключ и зашифрованные данные запроса. Первый совместно используемый секретный ключ может быть сгенерирован с помощью комбинированного кратковременного открытого ключа и статического закрытого ключа компьютера сервера. С помощью первого совместно используемого секретного ключа и первых вспомогательных данных может быть сгенерирован первый ключ сеанса. Зашифрованные данные запроса могут быть расшифрованы с помощью первого ключа сеанса для получения данных запроса, содержащих кратковременный открытый ключ, идентификатор пользовательского устройства и идентификационные данные. Идентификационные данные могут быть проверены. Могут быть извлечены аутентификационные данные, связанные с идентификатором пользовательского устройства, и идентификационные данные. С помощью аутентификационных данных и идентификационных данных может быть сгенерирован фактор идентификации. С помощью кратковременного открытого ключа и фактора идентификации может быть проверен комбинированный кратковременный открытый ключ. Может быть сгенерирован криптографический объект nonce. С помощью криптографического объекта nonce и фактора идентификации могут быть заблокированы статический открытый ключ компьютера сервера и/или статический закрытый ключ компьютера сервера. С помощью заблокированного статического закрытого ключа компьютера сервера и кратковременного открытого ключа пользовательского устройства может быть сгенерирован второй совместно используемый секретный ключ. Альтернативно, второй совместно используемый секретный ключ может быть сгенерирован с помощью статического закрытого ключа компьютера сервера и заблокированного кратковременного открытого ключа пользовательского устройства. С помощью второго совместно используемого секретного ключа и вторых вспомогательных данных может быть сгенерирован второй ключ сеанса. Дополнительное описание этих этапов может быть найдено со ссылкой на соответствующие этапы способа 600.

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

[0160] В некоторых вариантах осуществления ключ ограниченного использования (LUK) может быть определен необязательно. В некоторых вариантах осуществления LUK может быть сгенерирован на основе совместно используемого секретного ключа (например, первого совместно используемого секретного ключа или второго совместно используемого секретного ключа) и/или функции формирования ключа (KDF). В некоторых вариантах осуществления компьютер сервера может содержать базу данных, указывающую главный ключ формирования (MDK) для диапазона PAN/МАРКЕР, и определение LUK включает формирование LUK на основе MDK и PAN/МАРКЕР из платежной транзакции или из запроса регистрации.

[0161] На этапе 910 параметры формирования ключа (которые могут содержать LUK) могут быть включены в удостоверяющие данные. В некоторых вариантах осуществления могут быть включены другие удостоверяющие данные, включая параметры формирования криптограммы, параметры обновления и любые другие подходящие данные.

[0162] На этапе 911 могут быть выполнены этапы 613 и 614 способа 600. А именно, криптографический объект nonce, цепочка сертификатов компьютера сервера и удостоверяющие данные могут быть зашифрованы с помощью второго ключа для генерирования зашифрованных данных ответа. Сообщение с ответом предоставления, содержащее заблокированный статический открытый ключ компьютера сервера и зашифрованные данные ответа, может быть отправлено на пользовательское устройство. В некоторых вариантах осуществления сообщение с ответом предоставления, прежде чем дойти до пользовательского устройства, может проходить через одного или нескольких посредников (например, ненадежную сеть).

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

[0164] На этапе 912 регистрационные данные (например, одноразовый пароль (OTP)) могут быть предоставлены на пользовательское устройство. Компьютер сервера может представлять собой сервер регистрации, который может или не может быть таким же, что и сервер предоставления, описанный выше. Регистрационные данные могут быть переданы на пользовательское устройство с помощью отдельного канала связи по сравнению с каналом связи, используемым для передачи сообщений с запросом/ответом предоставления. Например, регистрационные данные могут быть переданы посредством SMS, электронного письма, телефонного вызова, онлайн-чата, факсимильного сообщения, почтовой связи и т. п., и введены пользователем вручную в пользовательское устройство. В некоторых других вариантах осуществления регистрационные данные могут быть предоставлены по тому же каналу связи, что и сообщения с запросом/ответом предоставления. В таких вариантах осуществления регистрационные данные могут быть предоставлены в сообщении с ответом предоставления или в другом сообщении.

[0165] На этапе 914 от пользовательского устройства может быть принята криптограмма регистрации. Криптограмма регистрации может быть предоставлена пользовательским устройством по тому же каналу связи, что и сообщения с запросом/ответом предоставления, или по отдельному каналу связи, такому как SMS, электронное письмо, телефонный вызов, онлайн-чат, факсимильное сообщение, почтовая связь и т. п.

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

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

Схема информационных потоков

[0168] На фиг. 10 показана схема информационных потоков приведенного в качестве примера процесса 1000 внесения в реестр согласно некоторым вариантам осуществления. Как показано на фиг. 10, пользовательское устройство 1002 может генерировать пару кратковременных мобильных открытого/закрытого ключей (ePubM/ePrivM). Пара кратковременных мобильных открытого/закрытого ключей может быть заблокированной. Пользовательское устройство 1002 может предоставлять кратковременный мобильный открытый ключ (ePubM) на компьютер 1004 сервера. Компьютер сервера может использовать кратковременный мобильный открытый ключ (ePubM) и серверный закрытый ключ (PrivS) для генерирования совместно используемого секретного ключа (Z⁰) с помощью функции Диффи-Хеллмана на эллиптических кривых (ECDH). Совместно используемый секретный ключ может быть известен как пользовательскому устройству, так и компьютеру сервера на обоих концах безопасного канала. Совместно используемый секретный ключ может быть основан на выборах согласованных параметров сервера, алгоритма и/или сертификата сервера. В некоторых вариантах осуществления совместно используемый секретный ключ (Z⁰) может содержать второй (ответный) совместно используемый секретный ключ, описанный в данном документе. Совместно используемый секретный ключ используют для создания нового рекуррентного совместно используемого секретного ключа (Zⁿ, или Следующий Z) для каждой последующей транзакции. В некоторых вариантах осуществления следующий совместно используемый секретный ключ может быть сформирован с помощью согласованной функции формирования ключа (например, AES) со статическими известными, но рандомизированными, искаженными или защищенными в криптографическом «белом ящике» параметрами.

[0169] Совместно используемый секретный ключ (Z⁰) и параметры данных формирования ключа (данные формирования) могут быть использованы для формирования ключа разового использования (SUK). Ключ разового использования может быть использован с алгоритмом аутентифицированного шифрования (AE) для шифрования таких данных, как сертификат сервера (Cert S) и данные формирования ключа (Данные формирования). Кроме того, в качестве входных данных функций KDF AES может быть использована рандомизация конфигурации выбора алгоритма и параметров (Конфигурация рандомизации). Конфигурации рандомизации может быть использована для затруднения понимания параметров формирования ключа и/или внедрения участка программного кода (VIP) для пользовательского устройства. Программный код может содержать комплект разработки программного обеспечения (SDK), связанный с платежным приложением (например, приложением электронного кошелька). Код может быть подписан сервером или другим поставщиком, так что пользовательское устройство может аутентифицировать код. Во время внедрения программный код может быть персонализирован или рандомизирован (например, на основе конфигурации рандомизации) для конкретных пользовательских устройств или групп пользовательских устройств, так что разные пользовательского устройства не демонстрируют согласованной схемы поведения ключа. В некоторых вариантах осуществления на стороне сервера предусмотрено по меньшей мере два уровня искажения. На первом уровне сервер может относительно случайным образом назначать разные способы вычисления формирований ключа и криптограмм на основе сочетания используемых атрибутов, порядка используемых атрибутов и ветви кода в коде, который нужно использовать. В некоторых случаях после того как сервер случайным образом выбрал набор атрибутов для формирования ключа, упорядочение атрибутов и/или ветвь кода для криптографического алгоритма, может быть сгенерирована битовая карта, которая содержит эти команды для передачи на пользовательское устройство в зашифрованных данных ответа. Таким образом, для каждого пользовательского устройства или каждой группы пользовательских устройств, и/или для каждой регистрации или повторной синхронизации, сочетание используемых атрибутов, порядок используемых атрибутов и ветвь кода в коде, который нужно использовать, будет разным. Этот подход затрудняет мошеннику обратную разработку программного кода или формирование ключа по украденным параметрам. На втором уровне разные наборы кода могут быть выпущены для разных групп устройств, таких как организация (например, банк эмитента), географическая область, или специальное приложение для организации. Таким образом, размер группы, на которое может быть нацелена обратная разработка, может быть изменен от всех приложений, принимающих определенные PAN, до подгрупп этой группы. Путем изменения программного обеспечения в разных группах пользовательских устройств этот подход ограничивает способность взломщика создавать злонамеренное программное обеспечение (например, вредоносные программы), которое можно повторно использовать на разных устройствах и, следовательно, вред от потенциального нарушения безопасности. В некоторых вариантах осуществления каждый выпуск приложения может использовать новый набор кода, но размер группы для нового набора кода предпочтительно является достаточно большим, чтобы быть подписанным и видимым в рамках одного онлайн магазина приложений (например, магазина Google Play или эквивалента).

[0170] Конфигурация рандомизации, данные (например, относящиеся к формированию ключа, параметрам обновления и/или формированию криптограммы) и сертификат сервера (Cert S) наряду с любой другой подходящей информацией могут быть зашифрованы для генерирования зашифрованных данных ответа. Например, зашифрованные данные ответа могут содержать зашифрованный сертификат сервера (CertS*) и зашифрованные данные (Данные*). Перед шифрованием данные (например, параметры формирования ключа) могут быть искажены с помощью случайной конфигурации. Как оговорено выше, данные могут содержать битовую карту, которая содержит команды, подлежащие передаче на пользовательское устройство относительно случайно выбранного набора атрибутов для формирования ключа, упорядочения атрибутов и/или ветви кода для криптографического алгоритма. Битовая карта может быть включена в зашифрованные данные ответа. Зашифрованные данные ответа могут быть предоставлены на пользовательское устройство 1002.

[0171] Пользовательское устройство 1002 может определять совместно используемый секретный ключ (Z) с помощью кратковременного мобильного закрытого ключа (ePrivM) и открытого ключа сервера (PubS), последний может быть предоставлен компьютером 1004 сервера. Пользовательское устройство 1002 может генерировать ключ разового использования (SUK) с помощью совместно используемого секретного ключа (Z⁰) и данных формирования. Данные формирования могут содержать ранее предоставленные параметры формирования ключа, параметры формирования криптограммы и т. п. Ключ разового использования (SUK) может быть использован для расшифровывания зашифрованных данных ответа (включая зашифрованные данные (Данные*), зашифрованный сертификат сервера (CertS*) для получения расшифрованных значений. Сертификат сервера (CertS) может быть проверен с помощью открытого ключа органа сертификации (PubCA) и алгоритма цифровой подписи на основе эллиптических кривых (ECDSA). В некоторых случаях некоторые или все расшифрованные данные (например, содержащие описанную выше битовую карту) могут быть дополнительно искажены (Конфигурация данных*) для хранения (например, с помощью технологии шифрования типа «белого ящика»).

[0172] SUK может быть использован для определения криптограммного ключа (CK), который используют для шифрования регистрационных данных (например, одноразового пароля (OTP)), сгенерированных компьютером 1004 сервера и переданных на пользовательское устройство 1002 по вторичному каналу. Вторичный канал может быть отдельным от безопасного канала, используемого для передачи сообщений с запросами и ответами между пользовательским устройством 1002 и компьютером 1004 сервера. Зашифрованные регистрационные данные (Зашифрованный OTP) затем могут быть предоставлены на компьютер 1004 сервера, который может расшифровать зашифрованные регистрационные данные (например, OTP) с помощью криптограммного ключа для проверки подлинности криптограммы регистрации.

Пример потока данных внесения в реестр

[0173] На фиг. 11 показана блок-схема приведенного в качестве примера процесса 1100 внесения в реестр согласно некоторым вариантам осуществления. Как показано на фиг. 11, в качестве части процесса идентификации и формирования ключа для внесения устройства в реестр, между пользовательским устройством 1102 (например, пользовательским устройством 101) и компьютером 1104 сервера (например, компьютером 105 сети обработки платежей или компьютером 106 эмитента) может быть произведен обмен четырьмя сообщениями.

[0174] В первом сообщении пользовательское устройство 1102 может предоставить на компьютер сервера идентификационные данные, относящиеся к пользовательскому устройству 1102 и/или пользователю, связанному с пользовательским устройством 1102. Например, идентификационная информация может содержать аутентификационные удостоверяющие данные, такие как имя пользователя и пароль. Кроме того, пользовательское устройство 1102 может генерировать пару кратковременных открытого/закрытого ключей и предоставить кратковременный открытый ключ в сеть 105 обработки платежей. В некоторых вариантах осуществления первое сообщение может быть передано по безопасному каналу связи. Например, первое сообщение может быть зашифровано с помощью ключа сеанса, сформированного из совместно используемого секретного ключа (Z₀), который определен по открытому ключу, связанному с компьютером 1104 сервера, и кратковременному закрытому ключу (EK).

[0175] Во втором сообщении компьютер сервера 1104 передает регистрационные данные (например, одноразовый пароль) на пользовательское устройство 1102. Как правило, регистрационные данные (например, одноразовый пароль) могут быть переданы на пользовательское устройство 1102 с помощью отдельного канала связи. Например, регистрационные данные (например, одноразовый пароль) могут быть переданы посредством SMS, электронного письма и т. п. и введены в пользовательское устройство 101 пользователем вручную.

[0176] Перед отправкой третьего сообщения с компьютера 1104 сервера на пользовательское устройство 1102 компьютер 1104 сервера может сформировать совместно используемый секретный ключ (Z₀), связанный с пользовательским устройством 1102, с помощью кратковременного открытого ключа, принятого от пользовательского устройства 1102, и закрытого ключа (PK), связанного с компьютером 1104 сервера. Совместно используемый секретный ключ может быть использован для генерирования ключа сеанса. Компьютер 1104 сервера также может определять параметры формирования ключа для пользовательского устройства 1102. «Параметр формирования ключа» может включать любую информацию, используемую для определения способа формирования ключа, такую как алгоритм формирования ключа, параметры для использования с алгоритмом и т. п. Например, в одном варианте осуществления параметры формирования ключа могут содержать битовую карту, которая идентифицирует один или несколько алгоритмов формирования ключа, которые необходимо использовать при формировании ключа на пользовательском устройстве 1102. Когда параметры формирования ключа определены, компьютер 1104 сервера может зашифровать параметры формирования ключа с помощью ключа сеанса и предоставить зашифрованные параметры формирования ключа на пользовательское устройство 1102. В некоторых вариантах осуществления третье сообщение также может содержать маркер (например, платежный маркер), который может быть зашифрован с помощью ключа сеанса.

[0177] В некоторых вариантах осуществления перечень алгоритмов (например, алгоритмов или функций формирования ключа) и параметров (например, параметров формирования ключа и/или параметров обновления), обсуждаемых в данном документе, может быть уникальным для конкретного устройства или конкретной группы устройств для того, чтобы предотвратить обратную разработку. Изменение от устройства к устройству может быть основано на комплекте разработки программного обеспечения (SDK), установленном на устройстве. В некоторых вариантах осуществления точный алгоритм и/или параметры, используемые для формирования конкретного ключа или совместно используемого секретного ключа, могут быть определены с помощью битовой карты, хранящейся на устройстве. Интерпретация битовой карты и отображение битовой карты на фактический перечень алгоритмов и/или параметров может изменяться зависящим от устройства SDK. Например, на одном устройстве перечень хранимых алгоритмов может иметь вид {alg1, alg2,..., alg8}, тогда как на другом устройстве список хранимых алгоритмов может иметь вид {alg3, alg5, …., alg1}. Аналогично, перечни параметров формирования ключа и/или параметров обновления также могут быть сохранены по-разному на разных устройствах. В некоторых вариантах осуществления алгоритмы и/или параметры могут быть внесены в перечень случайным образом на некоторых или всех устройствах. Битовая карта может указывать на правильный индекс в перечне алгоритмов и/или параметров, который необходимо использовать для фактического генерирования ключа. В некоторых вариантах осуществления данные ответа, предоставляемые компьютером сервера, могут содержать битовую карту, которая указывает на правильные алгоритмы и/или параметры, которые необходимо использовать пользовательскому устройству для генерирования ключей и/или совместно используемых секретных ключей. В некоторых случаях битовая карта, предоставленная компьютером сервера, может быть сгенерирована специально для данного пользовательского устройства на основе порядка, в котором алгоритмы и/или параметры хранятся на пользовательском устройстве.

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

[0179] Перед отправкой четвертого сообщения с пользовательского устройства 1102 на компьютер 1104 сервера, пользовательское устройство 1102 может расшифровать зашифрованные параметры формирования ключа с помощью ключа сеанса. Пользовательское устройство 1102 затем может сформировать криптограммный ключ (CK) с помощью параметров формирования ключа и совместно используемого секретного ключа. Пользовательское устройство 1102 может использовать криптограммный ключ для шифрования регистрационных данных (например, одноразового пароля), принятых во втором сообщении, чтобы определить криптограмму регистрации (RC). Пользовательское устройство 1102 затем отправляет четвертое сообщение, содержащее криптограмму регистрации, по безопасному каналу. Компьютер 1104 сервера также может формировать криптограммный ключ и генерировать криптограмму регистрации. Если принятая и сгенерированная криптограммы соответствуют, маркер, предоставленный на пользовательское устройство 1102, может быть активирован, и внесение в реестр пользовательского устройства 1102 может быть подтверждено. В некоторых вариантах осуществления как пользовательское устройство 1102, так и компьютер 1104 сервера могут сохранять криптограмму регистрации для будущего использования.

ТЕКУЩАЯ ПРОВЕРКА ПОДЛИННОСТИ С ПОМОЩЬЮ ОБНОВЛЯЕМЫХ СОВМЕСТНО ИСПОЛЬЗУЕМЫХ СЕКРЕТНЫХ КЛЮЧЕЙ

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

[0181] На фиг. 12-15 показаны некоторые примеры таких способов. В некоторых вариантах осуществления пользовательское устройство может включать пользовательское устройство 101 или 200, представленное на фиг. 1 и 2, соответственно. Компьютер сервера может включать устройство 102, 103, 104, 105, 106 или 300, представленное на фиг. 1 и 3, соответственно.

B. Пользовательское устройство

[0182] На фиг. 12 показан приведенный в качестве примера процесс или способ 1200 транзакции для проведения транзакции между пользовательским устройством и компьютером сервера согласно некоторым вариантам осуществления. Аспекты процесса 1200 могут быть выполнены пользовательским устройством 101 или 200, представленным на фиг. 1 и 2, соответственно.

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

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

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

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

[0187] На этапе 1212 криптограмма транзакции может быть использована для проведения транзакции (или другой защищенной связи). Как правило, криптограмма транзакции аутентифицирует транзакцию. Например, в некоторых вариантах осуществления пользовательское устройство может предоставить платежный маркер или PAN и криптограмму транзакции устройству доступа или компьютеру продавца, которые затем могут генерировать сообщение с запросом авторизации для транзакции. Сообщение с запросом авторизации может содержать криптограмму транзакции. Криптограмма транзакции может быть проверена субъектом, принимающим сообщение с запросом авторизации (например, компьютером 105 сети обработки платежей, компьютером 106 эмитента, проверяющим подлинность сервером), для определения, следует ли одобрить или отклонить транзакцию.

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

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

C. Компьютер сервера

[0190] На фиг. 13 показан приведенный в качестве примера процесс или способ 1300 транзакции для проведения транзакции между пользовательским устройством и компьютером сервера согласно некоторым вариантам осуществления. Аспекты процесса 1300 могут быть выполнены компьютером 102, 103, 104, 105, 106 или 200 сервера, представленным на фиг. 1 и 3, соответственно. В некоторых вариантах осуществления процесс 1300 выполняет проверяющий подлинность сервер, который может быть выполнен с возможностью обработки платежных транзакций.

[0191] На этапе 1302 может быть принята криптограмма транзакции для транзакции. Криптограмма транзакции могла быть сгенерирована пользовательским устройством с помощью способа 1200, представленного выше.

[0192] На этапе 1304 необязательно может быть обновлен совместно используемый секретный ключ. В некоторых вариантах осуществления совместно используемый секретный ключ может представлять собой совместно используемый секретный ключ, который определен как часть более раннего процесса предоставления, например, как описано выше. В других вариантах осуществления транзакция авторизации (например, для доступа к ресурсу, такому как документ или компьютер) может происходить одновременно с процессом предоставления. Обновление совместно используемого секретного ключа может быть выполнено любым подходящим способом. Например, обновленный совместно используемый секретный ключ может быть сгенерирован как функция предыдущего совместно используемого секретного ключа и другой информации, такой как идентификатор устройства. Сохраненный совместно используемый секретный ключ может быть обновлен для определения обновленного совместно используемого секретного ключа. Например, в одном варианте осуществления обновленный совместно используемый секретный ключ может представлять собой результат хеширования предыдущего совместно используемого секретного ключа и других данных. В некоторых вариантах осуществления следующий совместно используемый секретный ключ может быть определен с помощью параметров обновления, таких как параметры устройства и счета и конфигурационная информация. В некоторых вариантах осуществления параметры обновления могут быть уникальными для конкретного пользовательского устройства или конкретной группы пользовательских устройств. Наряду с совместно используемым секретным ключом может быть обновлена и другая информация (например, с помощью параметров обновления) для подготовки к генерированию следующего SUK, включая параметры формирования ключа, счетчики, объекты nonce, данные транзакции и т. п. В некоторых случаях такое генерирование обновленного секретного ключа и/или любой другой необходимой информации может быть выполнено, когда устройство находится в режиме офлайн. Как обсуждалось выше, любая информация, которая больше не нужна локально (например, предыдущий совместно используемый секретный ключ (ключи), предыдущие параметры формирования, данные транзакции и т. п.), может быть удалена, убрана или иным образом сделана недоступной, предпочтительно сразу же после или вскоре после времени, когда такая информация больше не нужна.

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

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

[0195] На этапе 1310 может быть проверена подлинность криптограммы. Например, проверка подлинности криптограммы может включать проверку того, что расшифрованная криптограмма содержит маркер или PAN, используемые для проведения транзакции. Проверка подлинности криптограммы также может включать проверку данных транзакции, содержащихся в расшифрованной криптограмме. Проверка подлинности криптограммы также может включать проверку того, что криптограмма и/или криптограммный ключ не были использованы многократно сверх разрешенных лимитов. Например, если криптограммный ключ представляет собой ключ разового использования (SUK), то один и тот же криптограммный ключ, используемый дважды, может указывать на то, что совместно используемый секретный ключ был раскрыт. Кроме того, в некоторых случаях, если подлинность криптограммы не может быть проверена в соответствии со следующим ожидаемым криптограммным ключом, ее подлинность может быть проверена в соответствии с предопределенным количеством будущих криптограммных ключей (например, 5 или менее). Это может обеспечить проверку подлинности без учета небольших проблем синхронизации (например, если две или более платежных транзакций обрабатывают в другом порядке, чем они были проведены, или если транзакция была отменена после того, как криптограмма была сгенерирована для транзакции, но до того, как транзакция была передана на компьютер сервера).

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

[0197] Если криптограмма является недействительной, транзакция может быть отклонена. Иначе, обработка транзакции может продолжаться (например, запрос авторизации на транзакцию может быть направлен на следующий компьютер сервера (например, от компьютера 105 сети обработки платежей на компьютер 106 эмитента).

Схема информационных потоков

[0198] На фиг. 14 показана схема информационных потоков процесса 1400 транзакции согласно некоторым вариантам осуществления. Как показано на фиг. 14, пользовательское устройство 1402 может определять совместно используемый секретный ключ (Z) и использовать совместно используемый секретный ключ (Z) наряду с другими параметрами формирования ключа (например, параметрами устройства и счета и/или конфигурационной информацией) в качестве входных данных для функции формирования ключа (AES KDF) для определения обновленного совместно используемого секретного ключа (Следующий Z). LUK, обновленный совместно используемый секретный ключ, параметры устройства и счета, конфигурационная информация, параметры транзакции (например, маркер, сумма транзакции, метка времени, случайное число и т. п.) и другая информация могут быть использованы в качестве входных данных для функции формирования ключа (AES KDF) для определения криптограммного ключа (CK). В некоторых вариантах осуществления AES является предпочтительным криптографическим алгоритмом, используемым для генерирования следующего совместно используемого секретного ключа и/или LUK (например, SUK) во время транзакции в силу его более быстрой работы по сравнению с другими способами (например, хешированием или операциями на основе эллиптической кривой (EC)). LUK мог быть предоставлен на пользовательское устройство 1402 ранее (например, во время процесса предоставления). Функция формирования ключа, которую используют для определения криптограммного ключа, может или не может быть той же, что и функция формирования ключа, которую используют для определения обновленного совместно используемого секретного ключа. Криптограммный ключ может быть ключом ограниченного использования. В одном примере криптограммный ключ является ключом разового использования (SUK), который действителен только для одной транзакции. Криптограммный ключ затем может быть использован для генерирования криптограммы для использования в транзакции. Криптограмма может быть сгенерирована, например, путем шифрования параметров транзакции (например, суммы транзакции, метки времени транзакции, случайного числа и т. п.) с помощью криптограммного ключа.

[0199] При принятии криптограммы транзакции компьютер 1404 сервера может формировать криптограммный ключ подобным же образом, как описано выше для пользовательского устройства 1402. Криптограмма может быть расшифрована с помощью криптограммного ключа, и расшифрованная криптограмма может быть проверена на подлинность способом, подобным описанному выше, на этапе 1310 способа 1300, представленного на фиг. 13.

Пример выполнения транзакции

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

[0201] Как показано на фиг. 15, мобильное приложение, работающее на пользовательском устройстве 1502 (например, пользовательском устройстве 101, представленном на фиг. 1), может быть использовано для проведения платежной транзакции. Например, пользовательское устройство 1502 может быть физически предоставлено продавцу (например, во время NFC-транзакции) или может отправить детали транзакции на компьютер 103 продавца по сети, такой как Интернет.

[0202] Для проведения транзакции пользовательское устройство 1502 может сначала обновить совместно используемый секретный ключ, хранящийся на устройстве (Z_n-1). Обновление совместно используемого секретного ключа может быть выполнено любым подходящим способом. Например, обновленный совместно используемый секретный ключ (Z_n) может быть сгенерирован как функция предыдущего совместно используемого секретного ключа (Z_n-1) и другой информации, такой как идентификатор устройства.

[0203] Когда обновленный совместно используемый секретный ключ (Z_n) определен, обновленный совместно используемый секретный ключ может быть использован для генерирования криптограммного ключа (CK). Криптограммный ключ может быть ключом ограниченного использования (LUK). В некоторых случаях криптограммный ключ может быть ключом разового использования (SUK). Криптограммный ключ может быть использован для генерирования криптограммы транзакции, которую передает пользовательское устройство 1502. Криптограмма транзакции может быть сгенерирована любым подходящим способом. Например, в некоторых вариантах осуществления криптограмма транзакции может представлять собой сочетание деталей транзакции (например, суммы транзакции, даты транзакции и т. п.) и деталей пользователя/счета (например, платежного маркера, завершения срока действия счета и т. п.), которые зашифрованы с помощью криптограммного ключа.

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

[0205] Криптограмма транзакции может быть отправлена через POS-устройство 102 и компьютер 104 эквайера на компьютер 1504 сервера (например, компьютер 105 сети обработки платежей или компьютер 106 эмитента). В некоторых вариантах осуществления криптограмма транзакции может быть включена в сообщение с запросом авторизации. Компьютер 1504 сервера может затем обновлять совместно используемый секретный ключ, связанный с пользовательским устройством 1502, определять криптограммный ключ, связанный с устройством, на основе обновленного совместно используемого секретного ключа, и использовать криптограммный ключ для расшифровки принятой криптограммы транзакции. Если криптограмма транзакции определена действительной, компьютер 1504 сервера может авторизовать транзакцию или вызывать дополнительную обработку транзакции (например, анализ на мошенничество). Иначе, если криптограмма транзакции определена недействительной, компьютер 1504 сервера может отклонить транзакцию.

СПОСОБЫ ОБНОВЛЕНИЯ КЛЮЧА

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

[0207] На фиг. 20-22 показаны некоторые примеры таких способов. В некоторых вариантах осуществления пользовательское устройство может включать пользовательское устройство 101 или 200, представленное на фиг. 1 и 2, соответственно. Компьютер сервера может включать устройство 102, 103, 104, 105, 106 или 300, представленное на фиг. 1 и 3, соответственно.

A. Пользовательское устройство

[0208] На фиг. 16 показан приведенный в качестве примера процесс или способ 1600 обновления для обновления в реестре или регистрации пользовательского устройства на компьютере сервера согласно некоторым вариантам осуществления. Аспекты процесса 1600 могут быть выполнены пользовательским устройством 101 или 200, представленным на фиг. 1 и 2, соответственно. В некоторых вариантах осуществления процесс обновления ключа может быть запущен в предопределенные интервалы времени после проведения ряда транзакций, когда возникает подозрение о нарушении безопасности криптограммного ключа, и т. п.

[0209] На этапе 1602, могут быть приняты вторые регистрационные данные (например, второй одноразовый пароль). Первые регистрационные данные могли быть приняты в предыдущем процессе регистрации, таком как этап 808, представленный на фиг. 8. В разных вариантах осуществления регистрационные данные могут содержать другие данные, вместо OTP или в дополнение к нему. Например, регистрационные данные могут содержать данные без паролей, такие как статическая строка, идентификатор уникального устройства или пользователя, фиктивные данные транзакции и т. п. Могут быть использованы любые другие регистрационные данные, пока они поддаются проверке.

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

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

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

[0213] На этапе 1606 на компьютер сервера может быть отправлено сообщение с запросом обновления. Сообщение с запросом обновления может содержать криптограмму регистрации. В некоторых вариантах осуществления криптограмма регистрации может представлять собой криптограмму, определенную во время начального процесса внесения в реестр, например, на этапе 812 способа 800. Криптограмма регистрации затем могла быть сохранена на пользовательском устройстве. Сообщение с запросом обновления также может содержать хеш вторых регистрационных данных и второй кратковременный открытый ключ пользовательского устройства. Сообщение с запросом обновления также может содержать другие данные, подобные данным, включенным в начальный запрос внесения в реестр/предоставления, такие как идентификационная информация устройства или пользователя, информация конфигурации клиента или служебные директивы.

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

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

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

[0217] На этапе 1610 может быть сформирован второй криптограммный ключ с помощью второго кратковременного закрытого ключа пользовательского устройства, открытого ключа компьютера сервера и/или вторых параметров формирования ключа. Первый криптограммный ключ мог быть сгенерирован ранее во время процесса предоставления (например, на этапе 810 способа 800). В некоторых вариантах осуществления новый совместно используемый секретный ключ может быть определен на основе второго кратковременного закрытого ключа пользовательского устройства и/или открытого ключа компьютера сервера. Новый совместно используемый секретный ключ и вторые параметры формирования ключа (которые могут или не могут содержать второй LUK) могут быть использованы для генерирования второго криптограммного ключа. В некоторых других вариантах осуществления второй совместно используемый секретный ключ может быть сгенерирован с помощью второго кратковременного закрытого ключа пользовательского устройства, открытого ключа компьютера сервера (который может или не может быть заблокирован) и/или вторых параметров формирования ключа.

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

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

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

B. Компьютер сервера

[0221] На фиг. 17 показан приведенный в качестве примера процесс или способ 1700 обновления для обновления в реестре пользовательского устройства на компьютере сервера согласно некоторым вариантам осуществления. Аспекты процесса 1700 могут быть выполнены компьютером сервера, таким как серверное устройство или компьютер 102, 103, 104, 105, 106 или 300. Например, процесс 1700 может быть осуществлен сервером регистрации, как обсуждается в данном документе. Альтернативно или дополнительно, аспекты процесса 1700 могут быть выполнены любыми другими подходящими субъектами.

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

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

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

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

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

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

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

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

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

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

C. Пример схемы информационных потоков при обновлении ключа

[0232] На фиг. 18показана блок-схема процесса 1800 обновления ключа согласно некоторым вариантам осуществления. Как показано на фиг. 18, в качестве части процесса обновления ключа между пользовательским устройством 1802 (например, пользовательским устройством 101) и компьютером 1804 сервера (например, компьютером 105 сети обработки платежей или компьютером 106 эмитента) может быть произведен обмен четырьмя сообщениями.

[0233] В первом сообщении компьютер сервера 1804 может предоставить на пользовательское устройство 1802 вторые регистрационные данные (например, одноразовый пароль). В некоторых вариантах осуществления регистрационные данные (например, одноразовый пароль) могут быть предоставлены с помощью альтернативного средства связи, такого как SMS или электронное письмо.

[0234] Во втором сообщении пользовательское устройство может предоставить на компьютер 1804 сервера криптограмму регистрации (RC), открытый ключ новой пары кратковременных открытого/закрытого ключей и хеш принятых регистрационных данных (например, одноразового пароля). Криптограмма регистрации (RC) могла быть получена во время изначального процесса внесения в реестр (например, согласно способу 800). Компьютер 1804 сервера может проверять криптограмму регистрации и хеш регистрационных данных (например, одноразового пароля) для аутентификации пользовательского устройства 1802.

[0235] В третьем сообщении, если пользовательское устройство 1802 аутентифицировано, компьютер 1804 сервера может предоставить на пользовательское устройство 1102 новые параметры формирования ключа. В некоторых вариантах осуществления в качестве части параметров формирования ключа компьютер 1804 сервера может необязательно предоставить на пользовательское устройство 1802 новый ключ ограниченного использования (LUK). Ключ ограниченного использования может быть использован для генерирования новых криптограммных ключей и/или новых криптограмм (например, криптограмм регистрации и/или криптограмм транзакции).

[0236] Перед отправкой четвертого сообщения пользовательское устройство может формировать новый совместно используемый секретный ключ (новый Z₀) с помощью нового кратковременного закрытого ключа (EK) и открытого ключа компьютера сервера и использовать новый совместно используемый секретный ключ (Z₀) и новые параметры формирования ключа для определения нового криптограммного ключа (нового CK). В некоторых вариантах осуществления, где новый LUK предоставляет компьютер 1804 сервера, новый криптограммный ключ также может быть сгенерирован на основе LUK. Новый криптограммный ключ затем может быть использован для генерирования новой криптограммы регистрации (новой RC). Например, новая криптограмма может быть использована для шифрования регистрационных данных (например, одноразового пароля), отправленных на пользовательское устройство 1802 в первом сообщении. Пользовательское устройство 1802 затем может отправлять новую криптограмму регистрации (новую RC) на компьютер 1804 сервера. Если подлинность новой криптограммы (новой RC) подтверждается, обновление ключа может быть успешно завершено.

СИНХРОНИЗАЦИЯ

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

[0238] Этот недостаток, связанный с нарушением синхронизации, может быть устранен по меньшей мере частично на стороне сервера путем разрешения серверу проверять подлинность криптограммы для приема или следующего криптограммного ключа (SUK), или следующего n (где n=1, 2, 3, …) криптограммного ключа (ключей) (например, SUK) после отклонения следующего криптограммного ключа. Например, если проверка подлинности криптограммы, сгенерированной с помощью обновленного криптограммного ключа, терпит неудачу, сервер может попытаться проверить подлинность криптограммы с помощью следующего+1 криптограммного ключа (сформированного из следующего+1 совместно используемого секретного ключа), следующего+2 криптограммного ключа (сформированного из следующего+2 совместно используемого секретного ключа) или т. п.

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

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

ДРУГИЕ ТИПЫ ТРАНЗАКЦИЙ

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

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

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

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

[0245] В разных вариантах осуществления ресурс может включать вычислительные ресурсы, которые доступны через вычислительное устройство. Такие вычислительные ресурсы могут включать объекты данных, вычислительные устройства или их аппаратные/программные компоненты (например, ЦП, память, приложения), услуги (например, веб-сервисы), виртуальные компьютерные системы, хранение или управление данными, сетевые соединения и интерфейсы и т. п. Например, ресурс может включать одно или несколько вычислительных устройств (например, настольный компьютер, портативный переносной компьютер, планшет, мобильный телефон), файлы или другие данные, хранящиеся в вычислительных устройствах, запоминающее устройство или устройство хранения данных, связанное с вычислительными устройствами, приложения, установленные на компьютерных устройствах, периферические устройства, связанные с вычислительными устройствами, такие как устройства ввода/вывода (например, клавиатура, мышь, микрофон, сенсорный экран, принтер), сетевые интерфейсы, услуги, предоставляемые вычислительными устройствами, и т. п. Вычислительные ресурсы могут включать сетевые или облачные услуги или функциональные возможности, предоставляемые поставщиками услуг. Вычислительный ресурс может включать одно или несколько запоминающих устройств, узлов, систем или их часть, такую как раздел, том, сектор и т. п. Вычислительные ресурсы также могут включать объекты данных, такие как удостоверяющие данные (например, имя пользователя, пароли, криптографические ключи, цифровые сертификаты). В таком случае для доступа к этим удостоверяющим данным могут быть затребованы главные удостоверяющие данные. Ресурс может включать материальные и/или нематериальные ресурсы. Материальные ресурсы могут включать устройства, здания и физические объекты. Нематериальные ресурсы могут включать, например, услуги и время.

ВЫЧИСЛИТЕЛЬНОЕ УСТРОЙСТВО

[0246] На фиг. 19 показана блок-схема высокого уровня компьютерной системы, которая может быть использована для осуществления любого из субъектов или компонентов, описанных выше. Подсистемы, показанные на фиг. 19, подключены через системную шину 1975. Дополнительные подсистемы включают принтер 1903, клавиатуру 1906, несъемный диск 1907 и монитор 1909, который подключен к адаптеру 1904 дисплея. Периферийные устройства и устройства ввода/вывода (I/O), которые соединяются с I/O контроллером 1900, могут быть соединены с компьютерной системой с помощью любого количества средств, известных в данной области техники, таких как последовательный порт. Например, последовательный порт 1905 или внешний интерфейс 1908 могут быть использованы для соединения вычислительного устройства с глобальной сетью, такой как Интернет, устройством ввода типа мышь или сканером. Соединение по системной шине 1975 позволяет центральному процессору 1902 осуществлять связь с каждой подсистемой и управлять выполнением команд из системной памяти 1901 или несъемного диска 1907, а также обмен информацией между подсистемами. Системная память 1901 и/или несъемный диск могут представлять собой машиночитаемый носитель.

[0247] Запоминающие носители и машиночитаемые носители для хранения кода или частей кода могут включать любые соответствующие носители, известные или используемые в данной области техники, включая запоминающие носители и средства связи, такие как, но без ограничения, энергозависимые и энергонезависимые, съемные и несъемные носители, реализованные любым способом или технологией для хранения и/или передачи информации, такой как машиночитаемые команды, структуры данных, программные модули или другие данные, включая ОЗУ, ПЗУ, ЭСППЗУ (электрически стираемое программируемое постоянное запоминающее устройство), флеш-память или другую запоминающую технологию, CD-ROM, цифровой универсальный диск (DVD) или другой оптический носитель, магнитные кассеты, магнитную ленту, запоминающее устройство на магнитных дисках или другие магнитные запоминающие устройства, сигналы данных, передачи данных или любые другие носители, которые могут быть использованы для хранения или передачи желаемой информации и к которым может осуществить доступ компьютер. На основании описания и указаний, представленных в данном документе, для специалиста в данной области техники будут очевидны другие пути и/или способы для осуществления разных вариантов осуществления.

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

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

[0250] Любые программные компоненты или функции, описанные в этой заявке, могут быть реализованы в виде программного кода, подлежащего выполнению процессором, с помощью любого подходящего компьютерного языка, такого как, например, Java, C, C++, C#, Objective-C, Swift или языка сценариев, такого как Perl или Python, с использованием, например, обычного или объектно-ориентированного подхода. Программный код может быть сохранен в виде последовательности команд или командных сигналов на машиночитаемом носителе для хранения и/или передачи. Подходящий энергонезависимый машиночитаемый носитель может включать оперативное запоминающее устройство (ОЗУ), постоянное запоминающее устройство (ПЗУ), магнитный носитель, такой как жесткий диск или гибкий диск, или оптический носитель, такой как компакт-диск (CD) или DVD (цифровой универсальный диск), флеш-память и т. п. Машиночитаемый носитель может представлять собой любое сочетание таких устройств хранения или передачи.

[0251] Такие программы также могут быть закодированы и переданы с помощью несущих сигналов, предназначенных для передачи по проводным, оптическим и/или беспроводным сетям, согласно разнообразным протоколам, включая Интернет. По сути, машиночитаемый носитель согласно варианту осуществления настоящего изобретения может быть создан с помощью сигнала данных, закодированного с помощью таких программ. Машиночитаемый носитель, закодированный с помощью программного кода, может быть расположен с совместимым устройством или предоставлен отдельно от других устройств (например, с помощью загрузки через Интернет). Любой такой машиночитаемый носитель может располагаться на или в одном компьютерном продукте (например, жестком диске, CD или целой компьютерной системе) и может быть представлен на или в разных компьютерных продуктах в системе или сети. Компьютерная система может содержать монитор, принтер или другое подходящее устройство отображения для выдачи пользователю любых результатов, упомянутых в данном документе.

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

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

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

[0255] Формы единственного числа обозначают «один или несколько», если иное не указано отдельно. Использование «или» предназначено для обозначения «включающего или», а не «исключающего или», если иное не указано отдельно.

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

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

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

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

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

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

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

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

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

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

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

генерирование пользовательским устройством запросного совместно используемого секретного ключа с помощью кратковременного закрытого ключа и статического открытого ключа сервера; и

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

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

5. Осуществляемый с помощью компьютера способ по п. 1, в котором ответный совместно используемый секретный ключ определяют без заблокированного ключа, при этом удостоверяющие данные содержат криптографический объект nonce, и при этом первый криптограммный ключ дополнительно формируют с помощью криптографического объекта nonce.

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

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

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

генерирование пользовательским устройством второй криптограммы с помощью второго криптограммного ключа; и

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

определение компьютером сервера запросного совместно используемого секретного ключа с помощью кратковременного открытого ключа и статического закрытого ключа сервера;

генерирование компьютером сервера ответного совместно используемого секретного ключа с помощью статического закрытого ключа компьютера сервера и кратковременного открытого ключа;

получение параметра формирования ключа для формирования первого криптограммного ключа из ответного совместно используемого секретного ключа;

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

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

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

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

формирование первого криптограммного ключа из ответного совместно используемого секретного ключа с помощью параметра формирования ключа;

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

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

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

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

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

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

генерирование второй криптограммы с помощью второго криптограммного ключа и параметра формирования криптограммы; и

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

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

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

прием компьютером сервера криптограммы регистрации пользователя от пользовательского устройства;

формирование первого криптограммного ключа из ответного совместно используемого секретного ключа с помощью параметра формирования ключа;

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

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

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

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

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

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

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

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

прием второй криптограммы регистрации от пользовательского устройства; и

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

20. Компьютерная система для генерирования криптограмм, содержащая:

память, которая хранит выполняемые компьютером команды; и

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

21. Компьютерная система для генерирования криптограмм, содержащая:

память, которая хранит выполняемые компьютером команды; и

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