Результат интеллектуальной деятельности: УПРАВЛЕНИЕ УЧЕТНЫМИ ДАННЫМИ В РАСПРЕДЕЛЕННОЙ ВЫЧИСЛИТЕЛЬНОЙ СИСТЕМЕ

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

Настоящая заявка основана на и испрашивает приоритет Европейской патентной заявки № 19178579.9, поданной 5 июня 2019, и Европейской патентной заявки № 19178583.1, поданной 5 июня 2019 года, содержание которых включено в настоящий документ во всей их полноте для всех целей.

Область техники, к которой относится РАСКРЫТИЕ

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

ПРЕДШЕСТВУЮЩИЙ УРОВЕНЬ ТЕХНИКИ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Фиг. 7 иллюстрирует вычислительный узел устройства согласно фиг. 6 более подробно;

Фиг. 8 иллюстрирует элементы в вычислительном узле согласно фиг. 7;

Фиг. 9 указывает поток транзакции в связи с операциями, выполняемыми узлом согласно фиг. 7;

Фиг. 10 показывает использование токенизации в варианте осуществления компоновки согласно фиг. 7-9;

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

Фиг. 12 иллюстрирует примерный подход к идентификации транзакций;

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

Фиг. 14 иллюстрирует глобальную модель управления ключами с отдельными режимами, управляемыми, как показано на фиг. 11;

Фиг. 15 иллюстрирует глобальную модель мониторинга, ассоциированную с моделью управления ключами согласно фиг. 11 и 14;

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

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

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

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

Фиг. 20 иллюстрирует использование подхода согласно фиг. 19 в доставке локального счетчика транзакций с использованием кода верификации карты (CVC) для применения с узлами согласно фиг. 7 и 8;

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

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

Фиг. 23 иллюстрирует подход для переноса информации учетных данных транзакции с использованием DPD (цифровые платежные данные) для применения с узлами согласно фиг. 7 и 8.

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

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

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

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

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

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

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

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

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

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

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

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

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

Для обычной транзакции, держатель карты будет использовать свою платежную карту 6 - или мобильное вычислительное устройство, такое как смартфон 11, приспособленный для использования в качестве бесконтактного платежного устройства, - для взаимодействия с терминалом 7 POS продавца 2. Однако в вариантах осуществления, релевантных для настоящего изобретения, держатель карты будет использовать свое вычислительное устройство, которое может быть любым или всеми из трубки сотового телефона, планшета, ноутбука, стационарного персонального компьютера или любого другого подходящего вычислительного устройства (здесь показана трубка сотового телефона или смартфон 11, но другие вычислительные устройства, такие как смарт-часы или другое носимое устройство, также могут использоваться), чтобы действовать либо как посредник для физической платежной карты 6, либо как виртуальная платежная карта, действующая только в цифровой области. Смартфон 11 может достигать этого с помощью мобильного платежного приложения и цифрового кошелька, как описано ниже. Смартфон 11 может использовать это, чтобы совершать сделки с терминалом 7 POS продавца с использованием NFC или другой бесконтактной технологии или чтобы выполнить оплату в ассоциации с услугой цифрового кошелька, как обсуждается ниже. Однако онлайн-транзакции с продавцом представляют особый интерес в связи с вариантами осуществления раскрытия, а не контактные или бесконтактные операции с терминалом 7 POS продавца. Чтобы выполнить онлайн-транзакцию, смартфон 11 может также взаимодействовать с сервером 12 продавца, представляющим продавца 2, по любому надлежащему сетевому соединению, такому как общедоступный Интернет, - соединение с продавцом может быть предоставлено посредством app или приложения на вычислительном устройстве.

Инфраструктура 5 схемы транзакций (инфраструктура транзакций) в данном случае обеспечивает не только вычислительную инфраструктуру, необходимую для работы схемы карт и обеспечения маршрутизации транзакций и других сообщений к сторонам-участникам, таким как эквайер 3 и эмитент 4, но также услугу 17 кошелька для поддержки цифрового кошелька на вычислительном устройстве держателя карты, и Интернет-шлюз 18 для приема транзакций на основе Интернета для обработки посредством инфраструктуры транзакций. В других вариантах осуществления, услуга 17 кошелька может быть предоставлена аналогично третьей стороной с соответствующим доверительным отношением с провайдером схемы транзакций. Чтобы поддерживать токенизацию, присутствует поставщик 19 услуги токена (вновь, это показано как часть инфраструктуры 5 транзакций, но может предоставляться третьей стороной с соответствующими доверительными отношениями), и инфраструктура схемы транзакций предоставляет услугу 16 цифрового разрешения для поддержки выполнения токенизированных цифровых транзакций и для взаимодействия с другими элементами системы, чтобы разрешать корректное выполнение транзакций, - эта услуга цифрового разрешения может включать в себя другие элементы, такие как предоставление услуги токена.

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

Фиг. 5 более подробно показывает элементы инфраструктуры транзакций для поддержки оцифрованных платежей с мобильного устройства. На этом чертеже, в качестве конкретного примера, показана принадлежащая заявителю архитектура Mastercard Cloud Based Payment (MCBP, Облачные платежи Mastercard) - это является иллюстративным, а не специфическим для изобретения и иллюстрирует то, как данная архитектура используется для поддержки мобильного платежного приложения 215 на мобильном устройстве (таком как смартфон 11), - в данном случае мобильное платежное приложение 215 показано как содержащееся внутри приложения кошелька или цифрового кошелька 41. Такой цифровой кошелек 41 может осуществлять связь с сервером 17 кошелька для разрешения управления мобильным платежным приложением, и он также может быть использован для запроса оцифровки платежной карты 6 для использования мобильным устройством 11.

Mastercard Digital Enablement Service (MDES, Услуга цифрового разрешения Mastercard) 42 выполняет множество функций для поддержки мобильных платежей и оцифрованных транзакций. Как указано выше, MDES 42 является только примером, - другие варианты осуществления могут использовать услуги оцифровки, токенизации и предоставления, ассоциированные, например, с другими инфраструктурами обработки транзакций. Сервер 17 кошелька не является частью MDES 42 - и не обязательно должен присутствовать, например, если мобильное платежное приложение 215 не встроено в цифровой кошелек 41, - но действует как интерфейс между мобильным устройством 11 и MDES 42. MDES 42 также опосредует токенизированные транзакции, так что они могут быть обработаны по схеме транзакций, как для обычных транзакций с картой. Следующими функциональными элементами, показанными в MDES 42, являются: система разрешения счета (AES) 43, система управления учетными данными (CMS) 44, хранилище 45 токенов и система управления транзакциями (TMS) 46. Они будут кратко описаны ниже.

Система разрешения счета (AES) 43 используется при оцифровке карты и установлении пользователем. Она будет взаимодействовать с мобильным платежным приложением (здесь через сервер 17 кошелька) для запросов оцифровки карт и будет заполнять хранилище 45 токенов по токенизации и будет взаимодействовать с CMS 44 для установления профиля карты с ассоциированными ключами для цифрового применения карты.

Система управления учетными данными (CMS) поддерживает управление учетными данными держателей карт и является ключевой системой в MDES 42. Основная система 441 управляет синхронизацией с системой транзакций в целом посредством взаимодействия с TMS 46 и управляет каналом к AES 43. Выделенная система 442 обеспечивает доставку необходимых элементов в мобильное платежное приложение, таких как оцифрованная карта и учетные данные и ключи в форме, необходимой для применения. Эта система также может взаимодействовать с сервером 17 кошелька для администрирования мобильного платежного приложения.

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

Система управления транзакциями (TMS) 46 используется при обработке токенизированных транзакций. Если транзакция идентифицируется схемой транзакций как токенизированная, она маршрутизируется в TMS 46, которая де-токенизирует транзакцию с использованием хранилища 45 токенов. Затем де-токенизированная транзакция маршрутизируется к эмитенту (здесь представлен системой 47 финансовой авторизации) для авторизации обычным образом. TMS 46 также взаимодействует с CMS 44 для обеспечения синхронизации в отношении счета и учетных данных держателя карты.

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

На фиг. 6 показана децентрализованная система вычислительных узлов Nx, каждый из которых способен выполнять как генерацию G, так и валидацию (подтверждение действительности) V учетных данных. Эти учетные данные могут быть действительными по всей системе, если только не ограничены некоторыми узлами в результате территориального регулирования или т.п., и в этом случае ассоциированы с транзакциями для набора пользователей (клиентов), транзакции которых маршрутизируются в такой узел, как правило, посредством географической близости. Узлы обеспечивают генерацию G учетных данных и валидацию V учетных данных как услуги клиентам и должны быть способны генерировать учетные данные безопасно и валидировать их безопасно, в то время как они действительны, по меньшей мере. В показанной архитектуре, учетные данные не хранятся - они генерируются по запросу и валидируются на лету (оперативно). Как показано на фиг. 6 и 7, в дополнение к генерации и валидации учетных данных, управление K и мониторинг М ключей могут рассматриваться как услуги как локально в узле, так и по всей системе, и управление доступом AC обычно потребуется для обеспечения доступа к услуге. Эти аспекты будут более подробно описаны ниже.

Элементы подходящего вычислительного узла показаны на фиг. 8. Узел 80 содержит по меньшей мере одно сетевое соединение 81 для обеспечения связи с клиентами 90 и другими узлами 91, а также (в данном примере) с центральным узлом 91a. Связь показана здесь как осуществляемая через отдельные сети к каждому набору других сторон - через первое облако 92 сети для соединения с клиентами и второе облако 92a сети для соединения с другими узлами в распределенной системе. Это отражает то, что эти сети могут быть физически различными или могут иметь различные требования и протоколы безопасности.

Узел 80 содержит множество обычных серверов 83 (которые будут содержать свои собственные процессоры и памяти - не показаны - вместе с другими компонентами, которые обычно будут иметься в сервере) и память 84, содержащую центральную базу данных. Также в узле 80 содержится множество аппаратных модулей 85 безопасности (HSM), выполненных с возможностью содержать криптографический материал и безопасно выполнять криптографические функции. Здесь элементы в узле 80 показаны как связанные посредством шины 86. Хотя узел 80 в этом случае представлен как один центр данных, это не является обязательным - "шина" может представлять собой, например, выделенное сетевое соединение между группой связанных центров данных, что позволяет им предоставлять ответ в реальном времени, так что они будет представляться другим объектам, осуществляющими связь с узлом, как часть единого целого.

Существующие процедуры управления учетными данными в платежных системах являются централизованными - любой запрос для создания или валидации учетных данных приводит к запросу в централизованную систему. Для платежной системы, реализующей стандарты EMV, учетные данные генерируются с использованием ключей, выведенных в соответствии с иерархическим процессом. Мастер-ключи эмитента (IMK) ассоциированы с конкретным диапазоном токенов, и ключи для использования для учетных данных выводятся иерархически (мастер-ключи карты - СМK - из IMK, и затем сеансовые ключи - SK - из CMK). Этот подход используется для устройств, таких как физические карты, но также используется для цифровых транзакций. Количество цифровых транзакций увеличивается чрезвычайно быстро, в отличие от взаимодействий на основе устройства, где рост является более согласованным с ресурсами.

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

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

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

В настоящее время модель безопасности устройства также используется для полностью цифровых транзакций. Эта модель безопасности включает в себя мастер-ключи эмитента (IMK), хранящиеся в системе транзакций HSM и используемые для выведения мастер-ключей карты (CMK) из релевантного IMK и PAN (номер первичного счета) карты. Эти CMK затем сохраняются в устройстве (как правило, защищенный элемент или заменяющая технология). При использовании решений на основе программного обеспечения для генерации учетных данных транзакции с использованием мобильного устройства, генерируется сеансовый ключ (SK) с использованием релевантного CMK и ATC (счетчик транзакций приложения) для карты/устройства - это в настоящее время генерируется системой управления учетными данными (CMS), как показано на фиг. 5. В настоящее время, все токены, даже для полностью цифровых транзакций, связаны с этим выведением IMK/CMK/SK. Это также применимо для учетных данных транзакции, генерируемых сервером через API, открываемый системой транзакций для удаленных платежных транзакций.

Этот подход требует очень высокой нагрузки управления для ключей, которая не является подходящей для полностью цифровых транзакций, как обсуждается ниже со ссылкой на фиг. 9 и 10. Генерация SK и, следовательно, криптограмм приложения (AC - стандартный механизм в транзакциях EMV) требует множества криптографических операций, не все из которых могут быть выполнены обычным стандартным HSM, так что требуются специализированные HSM. Требуется массовое распределение ключей по системе, чтобы выполнение транзакции могло поддерживаться, где бы она не происходила, и управление ATC является сложным. Было бы желательно использовать стандартные HSM, избегать массовой репликации ключей, в то же время имея ключи, непосредственно доступные для использования, и иметь возможность предоставлять решение, которое ограничивает количество HSM в целом (поскольку они обычно поддерживают только несколько тысяч ключей).

Большая часть этой защиты состоит в обеспечении гарантии безопасности, даже если имеется возможность компрометации в конечной точке системы (например, в устройстве держателя карты). Помимо этого, безопасность имеет ограниченную роль, как показано на фиг. 9. Основная цель криптографической функции состоит в обеспечении гарантии - это охватывает как целостность данных, так и аутентификацию. Связанные с транзакцией данные, защищенные криптографическими данными, включают в себя идентификацию транзакции и ассоциированного токена, вместе с указанием любых используемых криптографических процессов и любых релевантных финансовых данных (вместе с любым другим аспектом транзакции, которая должна быть гарантирована). Это представляется с помощью учетных данных транзакции, которые должны быть сгенерированы G и затем валидированы V, причем эти процессы контролируются M для обеспечения общей целостности системы и поддерживаются системой управления ключами K некоторого вида.

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

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

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

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

Для каждого узла, услуги генерации G и валидации V имеют доступ к пулу HSS. HSS содержат ключи, каждый из которых уникально идентифицирован набором идентификаторов ключа (KeyId). KeyId может представлять собой символ, значение, явно уникальное значение, такое как UUID, или что-либо еще с соответствующими свойствами. Эти KeyId хранятся в уникально идентифицируемых списках ключей (идентификаторов) - эти списки ключей обеспечивают список отношений между идентификатором (Id) и сохраненным ключом (KeyId). Идентификаторы (Id) представляют собой то, что будет определено детерминированным процессом, чтобы установить, какой ключ должен использоваться, как будет описано ниже.

Целостность каждого списка ключей гарантируется с использованием печати (Seal) - если списки ключей предоставляются из центрального местоположения, это может быть применено доверенной стороной, ассоциированной с этим центральным местоположением. Несколько других моделей распределения могут поддерживаться с использованием, например, доверенной стороны, являющейся локальной функциональностью вместо центрального местоположения. Узел, как правило, будет иметь несколько доступных списков ключей, но только с одним активным для генерации учетных данных (G) в данный момент времени, - однако, в общем случае необходимо для услуги валидации (V) иметь возможность осуществлять доступ к любому списку ключей, который может быть ассоциирован с учетными данными, которые все еще являются действительными. Ротация ключей в этом подходе является чрезвычайно простой, она может просто включать в себя замену активного списка ключей другим списком ключей. Однако очень просто сказать, какой KeyId необходим для валидации учетных данных, - он будет определен полностью идентификатором узла и ссылкой списка ключей. Эта информация является частью учетных данных и используется в качестве ввода в детерминированный процесс для выбора ключа из списка ключей.

Фиг. 11 иллюстрирует примерную компоновку для узла Ni, который имеет две услуги генерации G, способные генерировать учетные данные, ассоциированные с транзакциями. В любой данный момент времени, будет требоваться, чтобы эти услуги G использовали данный список ключей, например список ключей А в первом случае. Он использует желтый 111 и синий 112 ключи, так что эти ключи должны быть загружены в HSS, используемые услугами генерации G. По истечении периода времени, процесс ротации ключей может, например, разрешить использование списка ключей В, - он использует желтый 111 и синий 112 ключи, но также и зеленый 113 ключ, так что зеленый 113 ключ должен быть загружен в соответствующие HSM, если уже не присутствует. Конкретный ключ, который должен использоваться, выбирается из списка ключей детерминированным процессом, как будет обсуждаться ниже, - это обычно дает разный результат после ротации ключей, но это не является неизбежным случаем (например, Id=2 или Id=6 будет давать синий ключ до или после ротации). В то время как услуги генерации G не нуждаются в списке ключей А после ротации ключей, услуги валидации V все еще требуют этого - они требуют доступа к любому списку ключей, который относится к потенциально действительным учетным данным. Услуги валидации V должны быть способны устанавливать точно, какой ключ использовался для генерации учетных данных услугами генерации G, чтобы валидировать учетные данные.

Связанные с транзакцией данные, подлежащие криптографической защите, включают в себя идентификацию токена, ассоциированного с транзакцией, а также идентификацию самой транзакции. Для этого требуется некоторый вид идентификатора транзакции. В каждом узле, услуги генерации и валидации учетных данных имеют доступ к локальной базе данных, которая может использоваться для управления такими данными. Чтобы гарантировать, что транзакции эффективно управляются в системе, любая генерация учетных данных транзакции для данного токена должна быть ассоциирована с уникальным идентификатором транзакции для каждой транзакции. Это может быть UUID или любой подходящей структурой идентификатора (такой как конкатенация n-битного идентификатора узла, e-битного периода времени и c-битного локального счетчика).

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

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

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

Существует множество вариантов выбора, доступных для функции, но простейший выбор представляет собой операцию MOD, например, в данном случае Id=LTC MOD 10 может быть подходящим для обеспечения детерминированного результата, который может указывать на любое из доступных значений Id. Любая услуга валидации V с доступом к значению счетчика транзакций в данных транзакции (или любой счетчик, полученный из этого значения) может затем определять логический идентификатор ключа, который использовался услугой генерации G, которая генерировала учетные данные, и осуществлять доступ к корректному сохраненному ключу без какого-либо механизма проб и ошибок. Ассоциирование детерминированной функции процесса (называемой ниже keyList.GetIdFunction) с атрибутами списка ключей, таким образом, обеспечивает масштабируемое решение, которое может принимать любое количество идентификаторов логических ключей для данного списка ключей.

Криптографическая функция HSM должна быть подходящей для обеспечения целостности и аутентификации данных посредством генерации и валидации учетных данных. Криптографическая функция действует на выбранных данных транзакции, используя ключ, и предоставляет вывод, который не открывает ключ. Могут использоваться различные альтернативные криптографические функции - HMAC является особенно эффективным выбором, но CMAC, CBC MAC находятся в числе возможных альтернатив. Используемая криптографическая функция должна быть специфицирована в списке ключей (как keyList.CryptoFunction) и также приводится в действие функциональными возможностями HSM, используемых для генерации и валидации. Территориальное регулирование, экспорт криптографического материала или другие соображения безопасности могут привести к выбору конкретных криптографических функций.

В данных транзакции, должна быть информация, представляющая криптограмму приложения, сгенерированную в процессе транзакции. Это может быть сокращенной формой криптограммы, например, в унаследованных средах (таких как Mag Stripe или eCommerce), не способных переносить любые данные Цифровых безопасных удаленных платежей (DSRP) (с использованием поля EMV или UCAF), это может быть предоставлено в качестве поля CVC2. Это является важным, поскольку услуга валидации V должна иметь возможность осуществлять доступ ко всем данным, используемым службой генерации G, для генерации криптограммы, - это будет включать в себя следующее:

динамическая информация, переносимая как часть потока транзакций;

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

- реплицированные процессы (такие как управление списками ключей);

- системные параметры для конкретных случаев применения.

Стандартные подходы для различных случаев применения -унаследованная транзакция, транзакции поля UCAF и DPD -обсуждаются дополнительно ниже. Случаи применения унаследованной транзакции обеспечивают решение, когда продавец и/или PSP способны управлять PAN, датой истечения срока действия и CVC2 как частью потока транзакции, и не имеют доступа к более поздним разработкам. Случай применения UCAF нацелен на получение выгоды от недавно введенного универсального поля аутентификации держателя карты для переноса большего количества данных как части потока транзакций. Случай применения DPD охватывает введение цифровых данных платежа, контейнера, способного переносить все необходимые данные как часть потока транзакции.

Полный набор криптографических механизмов показан на фиг. 13. Управление ключами обсуждается со ссылкой на фиг. 14. Имеются два аспекта для управления ключами в этой модели: управление самими ключами, включая их генерирование и доставку в HSM, ассоциированные с узлами, и управление списками ключей, включая их генерацию, распределение, активацию и деактивацию. Списки ключей являются чувствительными активами, в то время как ключи рассматриваются как секретные активы - списки ключей определяют ключи, которые должны использоваться для генерации и валидации криптограмм. Ключи требуют сквозной безопасности при безопасном транспорте ключей с использованием методов упаковки/распаковки при загрузке ключей в HSM. Их применение не должно быть скомпрометировано списками ключей в случае, если злоумышленник хотел бы изменить содержимое списка ключей, чтобы изменить процесс выбора ключа. Целостность списков ключей гарантируется печатями - печать предоставляется для списка ключей генерирующей стороной или ассоциированной доверенной стороной, будет включать в себя подходящий криптографический процесс (такой как HMAC с соответствующим выделенным ключом или с использованием, например, цифровой подписи, сгенерированной с использованием асимметричных алгоритмов, такие как RSA, ECC, SM2…) и имеет эффект, состоящий в том, что любая релевантная часть системы может иметь уверенность в том, что список ключей был сгенерирован соответствующей стороной и не был модифицирован. Кроме того, печати списка ключей могут быть использованы в генерации и валидации криптограмм для защиты учетных данных.

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

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

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

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

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

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

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

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

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

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

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

Повторное использование полей транзакций в унаследованном случае может, таким образом, быть следующим. Для PAN, 14 разрядов (цифр) могут быть использованы для полной идентификации токена, при этом 1 разряд для счетчика, ассоциированного с токеном для данного числа, и один для контрольной цифры Луна (Luhn) (которая должна храниться в качестве контрольной суммы для обеспечения действительных чисел). 6 битов даты истечения срока действия можно определить по новому назначению, при этом х битов используются для идентификации узла, и y битов используются для ссылки на релевантный список ключей для этого узла. CVC2 обеспечивает три разряда, которые могут использоваться для криптограммы.

Для обеспечения безопасности, желательно изменять списки ключей на регулярной основе для обеспечения защиты системы от атак. Также важно иметь возможность разрешать валидацию учетных данных в течение некоторого периода после того, как они были созданы, - предлагаемый подход, состоит в том, чтобы разрешать валидацию учетных данных в течение до 24 часов после создания. Если это объединено с процессом ротации ключей, который работает каждые 24-36 часов, это означает, что в то время как процесс генерации будет постоянно иметь один активный список ключей для данного узла, процессу валидации потребуется только рассматривать два списка ключей (один в текущий момент активный для генерирования учетных данных и один активный непосредственно перед этим). Использование установленного детерминированного процесса на основе счетчика транзакций, таким образом, устанавливает ключ, который должен использоваться. Этот тип двоичной информации (то есть один или другой) может обычно кодироваться с использованием одного бита информации. Криптограмма играет ключевую роль в защите целостности транзакции - успешная валидация криптограммы, вычисленной по данному набору данных с использованием корректного ключа, подтверждает, что данные, первоначально использованные при генерации учетных данных, являются действительными. Любой сбой в процессе валидации может исходить из использования неверного криптографического материала и/или искаженных данных транзакции.

Примерный процесс ротации ключей для этой унаследованной компоновки показан на фиг. 17. Прежде всего, новые ключи предоставляются в HSM по мере необходимости - это может выполняться распределением из центрального источника или посредством другого процесса генерации ключей, например, посредством локальной генерации ключей. Затем генерируется новый список ключей - это может включать в себя существующие ключи и новые ключи - здесь, большинство сегментов в списке ключей включают в себя существующие ключи в новых положениях в списках ключей (хотя также возможно, что ключ останется в том же самом положении в списке ключей, как показано здесь для положений 2 и 6 списка ключей), хотя новый ключ также использовался в положениях 3, 7 и 8. Вновь, это может быть централизованным процессом, процессом, управляемым одноранговыми узлами в распределенной сети, или процессом, управляемым локально. Новый список ключей распределяется любой услуге валидации, пригодной для валидации, и одной услуге генерации, которая должна использовать его для генерации. Затем новый список ключей активируется в услугах валидации, а затем активируется в услуге генерации, что автоматически деактивирует ранее активный список ключей в этой услуге генерации, - процесс ротации ключей завершается в этот момент. Спустя 24 часа, предыдущий список ключей затем деактивируется для услуг валидации. Этот подход хорошо работает с ограниченным пространством, доступным для унаследованных случаев, - один бит может просто переключаться для указания, какой список ключей используется.

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

В каждом узле, каждая услуга генерации (G) и валидации (V) имеет доступ к локальной базе данных. Любая генерация учетных данных транзакции для данного токена ассоциирована с уникальным идентификатором транзакции для каждой транзакции. Локальный счетчик транзакций (LTC) управляется посредством "G" для данного токена в данном узле. Тот же самый процесс применяется во время валидации посредством "V". Эта информация переносится в поле PAN (разряд 15 или разряды 14 и 15) с флагом повторной попытки в поле даты истечения срока действия, с "полным счетчиком", сгенерированным, при необходимости, если LTC имеет более высокое значение. Однако важно установить лимит на количество криптограмм, которые могут генерироваться посредством G и валидироваться посредством V для данного токена для данного узла для данного списка ключей, чтобы гарантировать эффективное управление доступом, - это значение "MaxTransactionCounter" может быть сохранено в списке ключей и защищено печатью списка ключей.

Криптографические процессы для этого унаследованного случая показаны на фиг. 18. В этом случае, HMAC выбирается в качестве криптографической функции, так как это позволяет использовать HSS общего назначения при обеспечении эффективной функциональности. Идентификация токена использует значение PAN. Идентификация транзакции берет информацию из даты истечения срока действия (поле EMV DE 14) - конкретно, идентификатор узла и ссылку, возможно также с флагом повторной попытки, - и из поля PAN, которое удерживает счетчик. Идентификация ключа и криптографического способа предоставляется из счетчика (который устанавливает, какой ключ выбран из списка ключей) вместе с информацией, совместно используемой системой управления ключами в списках ключей. Различные поля, определяющие транзакцию, могут быть использованы в качестве финансовых данных, которые должны использоваться для генерации криптограммы (как показано на фиг. 18), со всеми этими полями, используемыми для генерации криптограммы, которая затем прореживается, и три наименее значимых разряда используются в поле CVC2.

Как будет понятно специалисту в данной области техники, некоторое изменение этих протоколов возможно, чтобы приоритизировать определенные варианты выбора или приоритеты. Например, может считаться желательным найти более эффективный путь переноса данных, таких как локальный счетчик транзакций, который не требует использования процесса повторной попытки, как можно видеть из фиг. 19, процесс, показанный выше, позволяет использовать максимум две цифры PAN для счетчика транзакций (и использование двух цифр ограничивает количество токенов, которые могут быть предоставлены), с уменьшенной криптограммой, удерживаемой в трех цифрах CVC. Другим подходом было бы использование только двух цифр, а не трех, поля CVC из криптограммы, при этом еще одна цифра используется для удерживания крайней правой цифры локального счетчика транзакций. Это может быть обеспечено более динамическим способом путем переупорядочения трех цифр в другом порядке; это могло бы быть сделано посредством добавления таблицы кодирования CVC к списку ключей, так что, когда используется список ключей, таблица кодирования, также защищенная печатью, определяет кодирование, подлежащее выбору для обеспечения поля CVC2. Код может быть выбран любым значением, известным как услуге G, так и услуге V, таким как контрольная цифра Луна для PAN. Новый список ключей затем может использовать полностью другую таблицу кодирования, делая процесс в значительной степени динамическим.

Эта компоновка показана на фиг. 20. Цифры PAN идентифицируют токен, а также обеспечивают контрольную цифру Луна, и контрольная цифра Луна используется для определения порядка цифр для поля CVC - в этом случае, выбрана опция 3, указывая наименее значимый разряд и следующий по значимости разряд криптограммы в первых двух местах, с наименее значимым разрядом счетчика в третьем месте. Это приводит к выводу CVC, который может быть получен как услугой G, так и услугой V.

Если используются более новые версии протокола электронной транзакции, то имеются другие поля, которые могут быть использованы для переноса большего количества информации. Например, когда доступно поле универсальной аутентификации держателя карты (UCAF), то могут быть использованы несколько дополнительных цифр, которые позволяют избежать компромиссов, используемых в унаследованном случае. Этот подход может высвобождать дополнительные 21 байта данных для переноса данных как части потока транзакций. Этого достаточно, чтобы разрешить перенос полного значения локального счетчика транзакций, избегая необходимости в каком-либо механизме повторной попытки. Может использоваться больше криптографического материала может использоваться - 8 байтов криптограммы, а не 2 или 3 цифр, большее количество узлов может быть использовано без идентификации узла, становящейся проблематичной из-за ограниченного доступного пространства в данных транзакции, как определено в требованиях протокола электронной транзакции. Также возможно выполнять ротацию списков ключей более часто, чем через 24 часа, так как имеется пространство для использования более одного бита для идентификации списка ключей для услуг валидации. Дополнительные признаки могут быть предоставлены, получая выгоду от использования доступного пространства в данных транзакции, например, посредством поддержки методов привязки к продавцу (когда транзакция эффективно связана с данным продавцом с использованием некоторой формы идентификации продавца), посредством включения дополнительных компонентов в криптографическом процессе, таких как использование какого-либо случайного элемента или начального числа между генератором и валидатором, или путем принятия дополнительных мер для обеспечения полной совместимости с какими-либо нормативными требованиями.

Как можно видеть из фиг. 21, при использовании новой компоновки для содержимого UCAF (например, формата 7), имеется 21 доступный байт. Один байт может быть разделен между идентификатором версии и кодовой книгой для указания условных данных, используемых в генерации криптограммы. Полный байт может использоваться, чтобы поддерживать локальный счетчик транзакций - это означает, что услуга генерации G будет способна генерировать до 255 криптограмм на список ключей для данного узла для данного токена, что должно исключить потребность в счетчике повторных попыток и решить проблему необходимости в учетных данных транзакции до того, как активируется новый список ключей. Дополнительный байт является достаточным для данных идентификатора узла и ссылки списка ключей, что оставляет полные 10 байт для условных данных, которые должны использоваться в генерации и/или валидации криптограммы - с каждым случаем использования, ассоциированным со значением в кодовой книге, - обеспечивая возможность использования данных иных, чем данные, переносимые в сообщении авторизации (переносимые данные могут включать в себя непредсказуемое число, используемое для транзакции, данные продавца, такие как тип продавца и акцептор карты или ID-кода учреждения-эквайера, информацию, относящуюся к сумме и т.д.). 8 байт могут использоваться для усеченной криптограммы, таким образом, значительно увеличивая безопасность. Фиг. 22 показывает, как криптографические процессы отличаются от того, что показано на фиг. 18 - PAN, LTC, идентификатор узла и ссылка могут быть все легко включены, и дополнительная информация может быть предоставлена в зашифрованных данных, таких как дополнительные поля транзакций, кодовая книга и другие условные данные.

Этот подход обеспечивает различные дополнительные возможности. Предоставление дополнительного бита для ссылки списка ключей позволяет в два раза превышать частоту ротации списка ключей. Хотя некоторые требования остаются - такие, как необходимость ограничения количества криптограмм, генерируемых услугой G для данного токена для данного узла для данного списка ключей, - другие снимаются (присутствие полного LTC означает, что нет необходимости в каком-либо процессе повторной попытки). Следует отметить, что список ключей может быть ограничен конкретным случаем применения - унаследованным, UCAF или DPD, - и это может быть использовано для определения конкретного лимита для счетчика транзакций для назначенного случая применения.

Новый формат, называемый DPD (цифровые платежные данные), должен быть введен в скором времени - это будет обеспечивать даже дополнительные опции, как показано на фиг. 23. DPD может переносить UCAF на учетные данные, как описано выше. В первой опции, уникальный идентификатор (такой как UUID) может быть определен услугой генерации во время создания транзакции и добавлен к списку данных, используемых в криптографическом процессе, - это обеспечивает возможность сквозного отслеживания учетных данных транзакции независимо от деталей транзакций, обеспечивая мониторинг и преимущества предотвращения мошенничества. Во второй опции, может использоваться намного большая кодовая книга, наряду с расширенной идентификацией узлов, хранением большего количества условных данных и применением стандартной усеченной криптограммы, как используется в другом потоке транзакции - вместе с UUID, как для первой опции.

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