Результат интеллектуальной деятельности: БЕЗОПАСНОЕ ВЗАИМОДЕЙСТВИЕ СЕРВЕР-КЛИЕНТ

Перекрестная ссылка на родственную заявку

Настоящая заявка пользуется преимуществом и испрашивает приоритет Европейской патентной заявки № 19190122.2, поданной 5 августа 2019. Полное раскрытие вышеуказанной заявки включено в настоящий документ посредством ссылки.

Область раскрытия

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

ПРЕДПОСЫЛКИ Раскрытия

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

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

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

Такой куки может использоваться, чтобы гарантировать серверу, что между сервером и пользовательским устройством установлено доверительное отношение, например, может быть установлено, что сервер может доверять комбинации браузера и устройств в пользовательском устройстве. Типичное отношение сервер-клиент показано на фиг. 1. Пользовательское устройство 1 - в принципе, любое вычислительное устройство, использующее браузер 11 в отношении клиент-сервер с сервером 12, - имеет процессор 2 и память 3, использующие операционную систему 6 для определения вычислительной среды 4, в которой работает браузер 11, причем куки 5 для браузера сохраняются в памяти в ассоциации с браузером 11. Сервер 12 аналогично имеет свою собственную вычислительную среду 14 с процессором 22 и памятью 23 и операционной системой 26, в этом случае исполняющими программное обеспечение 25 услуги. Куки 15, ассоциированные с программным обеспечением 25 услуги, сохранятся в серверной памяти 23 с ассоциированными данными 27. Это, разумеется, является минимальным описанием каждой системы - то, что описано здесь как "сервер 12", может быть гораздо более сложной системой, включающей в себя множество вычислительных систем, но для целей описания этого взаимодействия может рассматриваться как единая система.

Традиционный подход к использованию куки в этом контексте показан на фиг. 2а, и потенциальная атака третьей стороны показана на фиг. 2b. Для установления доверительного отношения, которое позволяет пользовательскому устройству 1 осуществлять доступ к безопасной услуге с использованием своего браузера 11, пользовательское устройство 1 предоставляет различные статические данные, чтобы идентифицировать пользовательское устройство 1 серверу 12. Эти статические данные выбираются, чтобы идентифицировать пользовательское устройство 1 - или комбинацию устройство/браузер - уникальным образом, и сервер 12 затем использует эти статические данные для генерации отпечатка (уникального идентификационного признака) устройства, который он ассоциирует с куки, который он затем предоставляет на пользовательское устройство 1. Куки может просто быть UUID или другим эффективно уникальным идентификатором. Отпечаток устройства хранится на сервере 12 в ассоциации с куки. При последующем взаимодействии, браузер предоставляет куки, и доступ к защищенной услуге предоставляется, если пользовательское устройство также способно обеспечить статические данные для установления того, что оно является тем же самым браузером, работающим на том же самом устройстве, что и первоначально идентифицированное.

Возможная атака показана на фиг. 2b. Злонамеренная третья сторона 21 получает некоторую степень доступа к пользовательскому устройству 1, что позволяет ей получать различные информационные элементы от этого устройства. Третья сторона также развивает знание требований доверительной услуги, - например, посредством легитимного взаимодействия с другой учетной записью, - и поэтому может определить статические данные, которые требовались бы сервером 12. Третья сторона затем получает куки и статические данные и пытается эмулировать комбинацию пользовательского устройства/браузера - третья сторона способна предоставить как куки, так и статистические данные, идентифицирующие устройство/браузер, поскольку она уже получила эти статические данные для пользовательского устройства 1. Это позволяет злоумышленнику эмулировать пользовательское устройство 1 и получить доступ к чувствительным или ограниченным ресурсам от сервера.

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

КРАТКОЕ ИЗЛОЖЕНИЕ СУЩНОСТИ ИЗОБРЕТЕНИЯ

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

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

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

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

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

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

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

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

Предпочтительно, отпечатком клиентского устройства является отпечаток комбинации устройства и браузера для клиентского устройства. Функция запроса может относиться к визуализации браузером клиентского устройства и может содержать стандартные программы JavaScript, относящиеся к визуализации браузером, например, с использованием процесса, который содержит одну или более из функций Canvas и WebGL. Такая функция запроса может содержать XOR запроса Canvas и запроса WebGL или любую другую функцию, которая комбинирует оба типа запросов эффективным образом.

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

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

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

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

Варианты осуществления раскрытия описаны ниже, в качестве примера, со ссылкой на приложенные чертежи, на которых:

Фиг. 1 показывает элементы архитектуры сервер-клиент, в которой могут быть использованы варианты осуществления настоящего раскрытия;

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

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

Фиг. 4 показывает первое взаимодействие между сервером и комбинацией клиент/браузер в соответствии с вариантом осуществления раскрытия;

Фиг. 5 показывает последующее взаимодействие между сервером и комбинацией клиент/браузер согласно фиг. 5;

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

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

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

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

Ниже со ссылкой на чертежи будут описаны общие и конкретные варианты осуществления раскрытия.

фиг. 1 иллюстрирует элементы типичной архитектуры сервер/клиент, как описано выше. Для краткости, пользовательское устройство 1 - в принципе, любое вычислительное устройство, использующее браузер 11, в отношении клиент-сервер с сервером 12 - имеет процессор 2 и память 3, использующие операционную систему 6 для определения вычислительной среды 4, в которой исполняется браузер 11, куки 5 для браузера сохраняются в памяти в ассоциации с браузером 11. В некоторых случаях, может иметься клиентское приложение 11а, исполняющееся на браузере 11. Аналогичным образом, сервер 12 имеет свою собственную вычислительную среду 14 с процессором 22 и памятью 23 и операционной системой 26, в этом случае исполняющую программное обеспечение 25 услуги. Куки 15, ассоциированные с программным обеспечением 25 услуги, хранятся в памяти 23 сервера. Разумеется, это является минимальным описанием каждой системы, - то, что описано здесь как сервер 12, может представлять собой гораздо более сложную систему, включающую в себя множество вычислительных систем, но для целей описания этого взаимодействия он может рассматриваться как единая система. Куки могут также в некоторых случаях не храниться как таковые, а регенерируются по мере необходимости на основе ассоциированных данных.

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

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

Затем устройство/браузер предоставляет 34 куки на сервер для повторного установления доверительного соединения между обоими, обычно в новом сеансе просмотра. В этот момент сервер устанавливает второй запрос и предоставляет 35 как первый запрос, так и второй запрос на устройство/браузер. Устройство/браузер определяет как первый ответ, так и второй ответ, и после использования первого ответа для кодирования второго ответа предоставляет 36 этот результат в качестве ответа на сервер. Сервер затем определяет 37, что первый ответ является корректным для повторного установления отношения, использует первый ответ для определения второго ответа, и сохраняет второй запрос и второй ответ с куки для использования при установлении отношения в следующий раз.

Этот подход комбинирует динамический механизм запроса/ответа с надежным отпечатком устройства/браузера, чтобы значительно снизить риск атаки.

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

На фиг. 4 показаны взаимодействия между web-браузером 11 клиентского компьютера 1 и сервером 12. Прежде всего, от клиентского компьютера 1 инициируется запрос, который должен быть запомнен 41 (это может быть в ответ на запрос принять куки от сервера 12 или может быть включен как часть другого процесса регистрации). В контексте, в котором предполагается использовать такие варианты осуществления, это, вероятно, должно быть ассоциировано с обеспечением некоторой услуги сервером 12 на клиентский компьютер 1, для которого желательно, чтобы сервер 12 установил, что клиентский компьютер 1 или, более конкретно, комбинация клиентского компьютера 1 и браузера 11 может быть доверительной.

Следующим этапом для сервера 12 является установка куки и передача его на браузер 11. Как таковой, куки может иметь любой традиционный формат и будет сохраняться в памяти 3 на клиентском компьютере 1 обычным образом. Куки может включать в себя другие технологии для обеспечения безопасной и эффективной идентификации и предоставления информации, например, может представлять собой куки Nudetect (технология, обеспечиваемая NuData Security), как описано в общих терминах в https://nudatasecurity.com/solutions/nudetect/. Информация, ассоциированная с куки и хранящаяся в ассоциации с ним на сервере 12, будет, однако, совершенно другой. При начальной установке куки, сервер 12 отправляет 42 не только куки, но также запрос (challenge_A), который будет использоваться при последующем взаимодействии (в следующий раз, когда будет представлен куки). В этом случае, запрос содержит детали изображения, подлежащего визуализации на клиентском компьютере 1 - случайный набор координат и цветов пространства вырезки для воспроизведения на стороне клиента с использованием стандартных JavaScript API Canvas и WebGL. Этот процесс и альтернативные подходы, которые могут быть использованы в альтернативных вариантах осуществления, описаны ниже со ссылкой на фиг. 6. Причина принятия этого подхода состоит в том, что результирующее визуализируемое изображение (IMG), как ожидается, является специфичным для графического процессора (GPU) (и ассоциированных драйверов), используемого браузером для аппаратного ускорения, и поддерживает некоторую форму идентификации устройства, так что может использоваться в качестве уникального идентификационного признака (отпечатка) для клиентского компьютера 1 (или, более конкретно, комбинации клиентского компьютера 1 и браузера 11).

При приеме куки и запроса, клиентский компьютер 1 вычисляет ответ (response_A1) на запрос. Здесь это делается с использованием Canvas и WebGL как часть функции, определенной в запросе, но эта функция может быть выведена из комбинации различных методов получения отпечатка браузера/устройства. Браузер 11 затем отправляет 43 этот ответ на сервер 12. Так как именно клиентский компьютер 1 рассматривается как находящийся под угрозой атаки, ни запрос, ни ответ не сохраняется на клиентском компьютере 1. Однако, когда ответ принят, то как запрос challenge_A, так и ответ response_A1 сохраняются 44 на сервере 12 в ассоциации с куки, и сервер подтверждает 45 браузеру 11, что это было сделано. В этот момент, куки был установлен и ассоциирован с отпечатком комбинации клиентского компьютера и браузера, но только с куки, сохраняемым на клиентском устройстве.

фиг. 5 иллюстрирует последующее взаимодействие (в этом случае, конкретно следующее взаимодействие, но дополнительные взаимодействия принимают прямо сопоставимый паттерн) между клиентским браузером 11 и сервером 12. Браузер 11 предоставляет 51 куки на сервер 12 обычным способом для указания того, что он известен серверу 12 - здесь, куки также указывает, что доверительное отношение устройства/браузера с сервером должно быть повторно установлено. Сервер 12 определяет 52, что сохранено для этого куки - это будет предыдущий запрос и ответ на предыдущий запрос, в этом случае challenge_A и response_A1. Как будет описано ниже, challenge_A эффективно используется в качестве криптографического ключа и также называется ниже K_CONF. На следующем этапе, сервер 12 отправляет 53 как старый запрос challenge_A, так и новый запрос challenge_В, вместе с некоторыми случайными данными RandomData. Клиентский компьютер 1 использует эту информацию следующим образом. K_CONF вычисляется клиентским компьютером 1 с использованием challenge_A, так что как клиентский компьютер 1, так и сервер 12 имеют эту информацию. Начальное число (seed) генерируется клиентом, и новый ключ K_MAC выводится из, но также отличается от, например, K_CONF:

K_MAC=seed XOR K_CONF

Значение seed предпочтительно является кратковременным и случайным. Ответы на запросы, которые предоставляются клиентским компьютером 1, несколько отличаются по форме от таковых на этапе установки, и теперь обеспечивают возможность проверки достоверности (валидации) на сервере 12 вместе с хранением пары запроса и ответа для использования при следующем взаимодействии (вновь, они будут сохраняться только на сервере 12, но не на клиентском компьютере 1). Ответ на исходный запрос не является просто результатом запроса (K_CONF), но значением, выведенным из него, в этом случае обычный ключевой хеш, использующий выведенный ключ K_MAC и RandomData:

response_A2=HMAC - SHA256(K_MAC, RandomData)

Ответ на новый запрос определяется как ранее с использованием Fn(challenge_В), но это теперь зашифровывается ключом, сформированным из исходного запроса, K_CONF:

response_В1=ENC(K_CONF, Fn(challenge_В))

Клиентский компьютер 1 отправляет 54 seed, response_A2 и response_В1 на сервер 12. Сервер способен проверять достоверность 55 ответа путем оценивания response_A2, так как он уже имеет K_CONF и RandomData, и принял seed от клиентского компьютера 1, так что он может сам генерировать ожидаемое значение response_A2. При совпадении значений response_A2, сервер будет затем дешифровать 56 response_В1 с использованием K_CONF, чтобы создать новую пару запроса и ответа, challenge_В и response_В1. Следовательно, response_В1 будет новым значением K_CONF для следующего запроса. Сервер 12 будет затем предоставлять доступ 57 к ограниченным или чувствительным ресурсам по мере необходимости, поскольку он переустановил доверительное отношение с парой компьютер/браузер клиента.

С использованием подхода, показанного на фиг. 5, тип атаки, рассмотренный на фиг. 2a и 2b выше, не будет эффективным. Даже если злоумышленник способен получать куки, он не сможет эмулировать комбинацию клиентского компьютера и браузера таким образом, чтобы обеспечить корректный ответ на запрос, и сервер 12 не будет предоставлять злоумышленнику доступ к чувствительным ресурсам. Дополнительные этапы могут быть приняты для минимизации риска атаки, в частности, измерение на сервере 12 времени, требуемого между предоставлением 53 запросов на компьютер 1 пользователя и предоставлением 54 ответов на запросы обратно на сервер 12. Если устанавливается пороговое значение времени около двух секунд, это должно обеспечить возможность генерации ответов на компьютере пользователя 1, но любая попытка злоумышленника предпринять контроль над компьютером 1 пользователя, а затем получать запросы, визуализировать требуемые изображения и вычислить требуемое HMAC, будет требовать времени больше этого.

Далее, со ссылкой на фиг. 6, рассмотрены подходящие опции для запроса. На фиг. 6 рассматриваются различные характеристики комбинации устройства/браузера. В общем, они будут изменяться во времени или между взаимодействиями для конкретной комбинации устройства/браузера. Другие характеристики - Screen Size (размер экрана) и Color Depth (глубина цвета); хеширование Canvas; хеширование WebGL; и Platform (платформа) - не будут. Из этих характеристик, имеется некоторое различие в простоте эмуляции, - в частности, размер экрана и глубина цвета могут быть эмулированы, как и платформа. Это оставляет Canvas и WebGL в качестве хороших кандидатов для функции запроса, при этом комбинация этих двух является особенно привлекательной.

В общем, в компьютерной науке, canvas (https://en.wikipedia.org/wiki/Canvas_(GUI)) представляет собой контейнер, который удерживает различные элементы рисования, которые используются для конструирования пользовательского интерфейса. Он реализуется в JavaScript для использования в web-браузерах. Предлагается использовать Canvas Text, использующий WebFont. Запрос может содержать случайный web-шрифт, случайный текст и базовый уровень текста. Функция будет визуализировать изображение текста в canvas для получения результата (IMG₁), который затем может быть хеширован (hash₁=SHA-256(IMG₁). Canvas обычно поддерживается в web-браузерах.

WebGL (https://en.wikipedia.org/wiki/WebGL) представляет собой JavaScript API для визуализации интерактивной 2D и 3D графики с любым совместимым web-браузером. WebGL 1.0 широко поддерживается в web-браузерах и будет соответствующим выбором - WebGL 2.0 является в настоящее время менее хорошо поддерживаемым, но может быть подходящим выбором в будущем, когда поддержка станет более общепринятой. Предлагаемый подход состоит в том, чтобы выполнять функцию на координатах и цветах пространства вырезки случайной формы, а затем вычислять хеш таким же образом, как для Canvas (hash₂=SHA-256(IMG₂)).

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

Fn(challenge)=hash₁ XOR hash₂

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

Фиг. 7 представляет собой блок-схему типичной четырехсторонней модели или четырехсторонней схемы платежных транзакций. Схема иллюстрирует объекты, присутствующие в модели, и взаимодействия, происходящие между объектами, работающими в схеме карты.

Платежные карты, такие как кредитные карты и дебетовые карты, очень широко используются для всех форм финансовой транзакции. Использование платежных карт получило значительное развитие в технологических разработках за последние годы. Первоначально, транзакции были на бумаге, использовали выходные данные карты транзакций и подтверждались подписью. Этот подход в значительной степени был заменен использованием магнитной полосы платежной карты, проводимой через считыватель магнитной полосы на торговом терминале (POS) для выполнения транзакции. Были разработаны карты транзакций, содержащие интегральную схему ("чип-карты" или "смарт-карты"), которая взаимодействует со считывателем смарт-карт в POS-терминале. Карты этого типа обычно работают согласно стандарту EMV для взаимодействия чип-карт и ассоциированного устройства (такого как POS-терминалы и ATM). ISO/IEC 7816 обеспечивает стандарт для работы карт этого типа. В настоящее время возможны бесконтактные платежи между соответствующими задействованными платежными картами или устройствами и терминалами продавца по беспроводной технологии ближнего действия с использованием протоколов NFC по EMV, которые охватываются стандартом ISO/IEC 14443. Платежные карты и устройства предоставляются по схеме транзакций (также называемой схемой карт), и механизм транзакций опосредуется инфраструктурой схемы транзакций.

Спецификации EMV относятся к протоколам контактных и бесконтактных платежей и общедоступны на web-сайте EMVCo (EMVCo является отраслевой организацией, задачей которой является ведение этих спецификаций с поддержкой провайдеров основной схемы транзакций) - https://www.emvco.com/document-search/ - и доступны для обращения специалистом в данной области техники. Терминология, связанная c технологией EMV, явно не определенная в этом документе, опирается на и определяется в спецификациях EMV, как будет понятно специалисту в данной области техники.

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

Четырехсторонняя модель может быть использована в качестве базы для сети транзакций. Для каждой транзакции, модель содержит четыре типа объектов: держатель 110 карты, продавец 120, эмитент 130 и эквайер 140. В этой модели, держатель 110 карты покупает товары или услуги у продавца 120. Эмитент 130 представляет собой банк или любое другое финансовое учреждение, выпускающее карту держателю 110 карты. Эквайер 140 предоставляет услуги для обработки карт продавцу 120.

Модель также содержит центральный коммутатор 150 -взаимодействия между эмитентом 130 и эквайером 140 маршрутизируются через коммутатор 150. Коммутатор 150 позволяет продавцу 120, ассоциированному с одним конкретным банком-эквайером 140, принимать платежные транзакции от держателя 110 карты, ассоциированного с другим банком-эмитентом 130.

Типичная транзакция между объектами в четырехсторонней модели может быть разделена на две основные стадии: авторизацию и расчеты. Держатель 110 карты инициирует покупку товара или услуги у продавца 120 с использованием своей карты. Подробности карты и транзакции отправляются эмитенту 130 через эквайер 140 и коммутатор 150 для авторизации транзакции. Если транзакция будет рассматриваться как транзакция повышенного риска эмитентом 130, то от держателя 110 карты может потребоваться выполнить дополнительный процесс верификации для проверки его идентичности и подробностей транзакции. Как только дополнительный процесс верификации завершен, транзакция авторизуется.

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

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

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

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

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

В общем, держатель 101 карты использует свое вычислительное устройство - которое может быть любым или всеми из сотового телефона, планшета, ноутбука, статического персонального компьютера или любого другого подходящего вычислительного устройства (здесь персональный компьютер 111 и сотовый телефон или смартфон 121 показаны в качестве альтернативы), - это может быть использовано в качестве способа, чтобы использовать информацию карты во взаимодействии клиент/сервер или действовать непосредственно в качестве посредника для физической платежной карты 106 или в качестве виртуальной платежной карты, работающей только в цифровой области. Смартфон 121 реализует это с использованием приложения мобильного платежа и цифрового кошелька, как описано ниже. Таким образом, смартфон 121 способен выполнять транзакцию с POS-терминалом 107 продавца с использованием NFC или другой бесконтактной технологии. Однако онлайн-транзакции представляют особый интерес в связи с вариантами осуществления раскрытия, а не контактными или бесконтактными транзакциями с POS-терминалом 107 продавца. Для выполнения онлайн-транзакции, вычислительное устройство пользователя - например, персональный компьютер 111 - может также быть способным взаимодействовать с сервером 12 продавца, представляющим продавца 2, по любому подходящему сетевому соединению, такому как общедоступный Интернет. Любое другое подходящее вычислительное устройство может использоваться держателем 1 карты для осуществления онлайн-транзакции таким образом.

Инфраструктура 105 схемы транзакций (инфраструктура транзакций) обеспечивает здесь не только вычислительную инфраструктуру, необходимую для работы схемы карты, и маршрутизацию транзакций и других сообщений участникам, таким как эквайер 103 и эмитент 104, но также услугу 117 кошелька для поддержки цифрового кошелька на вычислительном устройстве держателя карты, и Интернет-шлюз 118 для приема транзакций на основе Интернета для обработки посредством инфраструктуры транзакций. В других вариантах осуществления, услуга 117 кошелька может быть предоставлена аналогично третьей стороной с соответствующим доверительным отношением с провайдером схемы транзакций. Для поддержки токенизации, присутствует провайдер 119 услуг токена (вновь, это показано как часть инфраструктуры 105 транзакций, но может предоставляться третьей стороной с соответствующими доверительными отношениями), и инфраструктура схемы транзакций предоставляет услугу 116 цифрового разрешения для поддержки выполнения токенизированных цифровых транзакций и для взаимодействия с другими элементами системы для корректного выполнения транзакций.

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

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