Защита данных с переводом

Защита данных с переводом

Иллюстрации

Показать все

Реферат

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

[0001] Настоящая заявка является родственной по отношению к Предварительной Заявке США № 61/583,550, поданной 05 января 2012 г. (Регистрационный Номер №: 79900-819288), которая для всех целей во всей своей полноте включена в настоящий документ посредством ссылки. Настоящая заявка также является родственной по отношению к Предварительной Заявке США № 61/607,546, поданной 06 марта 2012 г. (Регистрационный Номер №: 7900-829470), которая для всех целей во всей своей полноте включена в настоящий документ посредством ссылки. Настоящая заявка дополнительно является родственной по отношению к Предварительной Заявке США № 61/704,428, поданной 21 сентября 2012 г. (Регистрационный Номер №: 79900-851259), которая для всех целей во всей своей полноте включена в настоящий документ посредством ссылки.

УРОВЕНЬ ТЕХНИКИ

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

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

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

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

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

[0006] В одном варианте осуществления описывается способ. Способ включает в себя этап, на котором шифруют личный идентификационный номер (PIN) устройством доступа. Шифрование PIN использует первый вариант ключа шифрования, основанный на исходном ключе. Устройство доступа шифрует уязвимые данные, используя второй вариант ключа шифрования, основанный на исходном ключе. Сообщение запроса авторизации, включающее в себя зашифрованный PIN и зашифрованные уязвимые данные, передается хост-серверу.

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

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

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

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

[0011] Эти и прочие варианты осуществления более подробно описываются ниже.

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

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

[0013] Фиг. 2 является иллюстративной блок-схемой для шифрования PIN и уязвимых данных на устройстве доступа и хосте торговца.

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

[0015] Фиг. 4 является иллюстративной блок-схемой для перевода PIN и уязвимых данных на хосте.

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

[0017] Фиг. 6 является таблицей, показывающей иллюстративную спецификацию для структуры и содержимого дорожки два платежного устройства.

[0018] Фиг. 7 является блок-схемой, иллюстрирующей реализацию шифрования с сохранением формата в соответствии с вариантом осуществления.

[0019] Фиг. 8 является блок-схемой, иллюстрирующей интерпретацию данных для определения того, было ли применено шифрование с сохранением формата.

[0020] Фиг. 9 изображает иллюстративную высокоуровневую структурную схему компьютерной системы.

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

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

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

[0023] Сообщение запроса авторизации может иметь определенный формат, чтобы способствовать осуществлению запросов и ответов между точками в финансовой сети. Например, сообщение запроса авторизации может быть стандартизованным сообщением обмена, таким как сообщение, которое соответствует стандарту Международной Организации по Стандартизации (ISO) 8583, который является стандартом для систем, которые осуществляют обмен электронными транзакциями. Сообщение стандарта ISO 8583 может включать в себя индикатор типа сообщения, одну или более битовых карт, указывающих на то, какие элементы данных присутствуют в сообщении, и элементы данных сообщения. Данные, включенные в сообщение запроса авторизации, могут включать в себя данные, полученные от платежного устройства, как, впрочем, и прочие данные, относящиеся к транзакции, владельцу платежного счета и торговцу. Например, сообщение запроса авторизации может включать в себя личный идентификационный номер (PIN), и уязвимые данные, такие как первичный номер счета (PAN), имя держателя карты, и дискреционные данные. Дополнительно, сообщение запроса авторизации может включать в себя дату истечения срока действия платежного устройства, код валюты, сумму транзакции, отметку транзакции торговца, город акцептанта, штат/страну акцептанта, транзитный номер маршрутизации, идентификационные данные терминала, идентификационные данные сети, и т.д. Сообщение запроса авторизации может быть защищено при помощи шифрования для того, чтобы предотвратить раскрытие данных.

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

[0025] Личный идентификационный номер (PIN) может быть цифровым паролем, обмен которым осуществляется между пользователем и системой и который используется для аутентификации пользователя системой. Блок PIN может быть зашифрованным блоком данных, используемым для инкапсуляции PIN. Блок PIN может быть составлен из PIN, длины PIN и поднабора PAN.

[0026] Дискреционные данные эмитента (IDD), также именуемые как «дискреционные данные», могут быть данными, которые размещаются на Дорожке 1 и/или Дорожке 2 магнитной ленты или чипе платежного устройства или иным образом ассоциированы с платежным счетом. IDD могут быть переменными по длине и могут содержать данные проверки покупателя и/или карты, такие как значение смещения PIN, значение проверки PIN (PVV), значение проверки карты (CVV), и т.д. IDD также могут включать в себя прочие данные, которые определены торговыми марками и/или эмитентами карты, такие как информация, используемая в программе лояльности, данные корпоративного обслуживания, и т.д.

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

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

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

[0030] «Устройство доступа» может относиться к устройству, которое принимает информацию от платежного устройства для инициирования транзакции. Например, устройством доступа может быть устройство точки продажи, выполненное с возможностью считывания данных счета, закодированных на магнитной ленте или чипе портативного устройства покупателя формата карты. Другие примеры устройств доступа включают в себя сотовые телефоны, PDA, персональные компьютеры, серверные компьютеры, планшеты, переносные специализированные считывающие устройства, абонентские приемники, электронные кассовые аппараты, банкоматы (ATM), виртуальные кассовые аппараты, киоски, системы безопасности, системы доступа и подобное. Устройства доступа могут использовать средства, такие как радиочастотные (RF) считывающие устройства или считывающие устройства с магнитной ленты для взаимодействия с платежным устройством. Устройство доступа может быть устройством, расположенным в физическом местоположении торговца, или может быть виртуальной точкой продажи, такой как web-сайт, который является частью транзакции формы электронной коммерции (электронной коммерции). При транзакции формы электронной коммерции владелец счета может вводить данные платежного счета в портативное устройство связи, персональный компьютер или иное устройство, выполненное с возможностью осуществления связи с компьютером торговца. При других транзакциях без участия карты, таких как транзакции заказа через почту или заказа по телефону, информация может быть введена в компьютер торговца, выступающего в роли устройства доступа. В дополнительном примере связь может происходить между бесконтактным элементом портативного устройства связи и устройством доступа, таким как считывающее устройство торговца или терминал точки продажи, посредством использования механизма беспроводной связи, такого как связь ближнего поля (NFC), RF, инфракрасная, оптическая связь и т.д.

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

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

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

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

[0035] Промышленные стандарты безопасности данных для платежных карт (PCI DSS) являются набором требований, применяемых к объектам, задействованным в обработке транзакции. Цель требований состоит в обеспечении безопасности финансовых данных.

[0036] Схема с Извлекаемым Уникальным Ключом для Каждой Транзакции (DUKPT) является схемой управления ключами, которая может получать уникальный ключ транзакции для каждой транзакции. DUKPT использует базовый ключ извлечения (BDK), который, как правило, известен только стороне, которая инициализирует TRSM, и получателю сообщения, зашифрованного посредством TRSM. В TRSM, как правило, внедряется исходный ключ, который извлечен из BDK. Ключ транзакции может быть извлечен из исходного ключа. Если извлеченный ключ раскрыт, то будущие и прошлые данные транзакции остаются защищенными, поскольку следующие или предыдущие ключи не могут быть легко определены из извлеченного ключа. DUKPT может быть использована для шифрования данных, ассоциированных с транзакцией электронной коммерции, таких как PIN и/или уязвимых данных.

[0037] Например, клавиатура ввода PIN может включать в себя TRSM с внедренным уникальным исходным ключом и серийным номером ключа. Клавиатура ввода PIN может генерировать уникальный ключ для каждой транзакции. Сообщение запроса авторизации, генерируемое клавиатурой ввода PIN, может включать в себя зашифрованный блок PIN и серийный номер ключа. Сообщение запроса авторизации может быть передано от клавиатуры ввода PIN хост-серверу торговца со своим собственным TRSM. TRSM хост-сервера торговца может использовать серийный номер ключа (KSN) для восстановления базового ключа извлечения (BDK), используемого при генерировании уникального исходного ключа клавиатуры ввода PIN. TRSM может использовать BDK и KSN для дешифрования зашифрованных данных.

[0038] Алгоритм Трехкратного Шифрования Данных (TDEA), также именуемый как «Стандарт Трехкратного Шифрования Данных», «3DES», «Трехкратный DES» и «TDES», является блочным шифром, который применяет алгоритм шифра Стандарта Шифрования Данных (DES) три раза к каждому шифруемому блоку данных.

[0039] «Ключ Шифрования Зоны» (ZEK) может указывать один или более ключей, используемых для шифрования данных между двумя конкретными точками (например, между хостом и сетью обработки платежей). Отдельные ZEK могут быть использованы для PIN или для уязвимых данных. В предпочтительном варианте осуществления ZEK используется только для шифрования уязвимых данных между сторонами и предпочтительно не является таким же, как PIN, MAC или другие конкретные ключи шифрования.

[0040] «Сервер» может включать в себя один или более компьютеров. Несколько компьютеров сервера могут быть соединены с возможностью осуществления связи через сетевые соединения, такие как проводные, беспроводные и/или интернет сетевые соединения. Один или более компьютеров сервера могут хранить базы данных.

ШИФРОВАНИЕ И ПЕРЕВОД ЗОНЫ PIN И УЯЗВИМЫХ ДАННЫХ

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

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

[0043] При типичной транзакции платежное устройство 102 взаимодействует с устройством 104 доступа для инициирования транзакции. Устройство 104 доступа может включать в себя модуль 106 безопасности с защитой от вмешательства (TRSM) устройства доступа. TRSM 106 устройства доступа может быть физически и/или с возможностью связи соединен с (или может быть неотъемлемым компонентом) устройством 104 доступа. Устройство доступа может принимать информацию, ассоциированную с платежным устройством 102, включая уязвимые данные, когда платежное устройство 102 взаимодействует с устройством 104 доступа. В некоторых вариантах осуществления устройство 104 доступа принимает уязвимые данные и/или PIN от устройства, хранящего информацию счета, такого как портативное устройство связи.

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

[0045] В других вариантах осуществления информацией платежного устройства может быть ввод пользователя, который принимается устройством 104 доступа. Данные PIN могут быть приняты от платежного устройства 102 или через ввод пользователя, принятый посредством устройства 106 доступа.

[0046] Когда устройство 104 доступа принимает данные, такие как PIN и информацию платежного устройства, TRSM 106 может зашифровать данные. В некоторых случаях может потребоваться получить PAN перед шифрованием PIN. Уязвимые данные, такие как PAN, имя держателя карты, адрес держателя карты, и дискреционные данные могут быть определены из информации, принятой от платежного устройства 102. Уязвимые данные могут быть получены путем анализа данных дорожки, полученных устройством 104 доступа от платежного устройства 102. В некоторых вариантах осуществления устройство 106 доступа шифрует PIN посредством генерирования блока PIN, основанного на PIN, длины PIN и поднабора PAN. Устройство 104 доступа может шифровать уязвимые данные, включающие в себя одно или более из следующего: PAN, имя держателя карты, адрес держателя карты, дискреционные данные и любую иную информацию, которая рассматривается в качестве уязвимых данных.

[0047] TRSM 106 устройства доступа может хранить исходный ключ, используемый для шифрования данных. Для каждой транзакции из исходного ключа может быть извлечен один или более ключей транзакции. Для соответствия требованиям, таким как PCI DSS, может потребоваться, чтобы разные ключи транзакции применялись к PIN и уязвимым данным. PIN может быть зашифрован, используя первый ключ транзакции, извлеченный из исходного ключа, а уязвимые данные могут быть зашифрованы, используя второй ключ транзакции, извлеченный из исходного ключа. Таким образом, как PIN, так и уязвимые данные могут быть зашифрованы, используя одну и ту же схему управления ключами (такую как DUKPT) и один и тот же алгоритм шифрования (такой как TDEA).

[0048] Сообщение запроса авторизации, включающее в себя данные PIN и зашифрованные уязвимые данные, может быть сгенерировано устройством 104 доступа и передано хост-серверу 108 торговца. Сообщение запроса авторизации может включать в себя назначенные поля для различных типов данных. Когда шифрование применяется к данным в сообщении запроса авторизации, шифрование может менять параметры (такие как тип данных, длина данных, и т.д.) поля, ассоциированного с зашифрованными данными. Благодаря измененным параметрам зашифрованные данные могут быть помещены в новое поле. Например, сообщение запроса авторизации может включать в себя поле с таким размером, чтобы вмещать PAN. Когда применяется шифрование, PAN и прочие уязвимые данные могут быть помещены в одно или более альтернативных полей сообщения запроса авторизации. В сообщение запроса авторизации может быть добавлено поле для сигнализации того, что зашифрованный PAN находиться в поле зашифрованного PAN. Уязвимые данные, такие как PAN, имя держателя карты, и дискреционные данные могут быть зашифрованы в устройстве 104 доступа и помещены в отдельные элементы внутри поля сообщения запроса авторизации, такого как поле 53 сообщения запроса авторизации в формате ISO.

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

[0050] Хост-сервер 108 торговца может включать в себя TRSM 110 хоста торговца. TRSM 110 хоста торговца может быть с возможностью связи и/или физически соединен с или может быть неотъемлемым компонентом хост-сервера 108 торговца. В некоторых вариантах осуществления TRSM 110 хоста торговца может быть расположен удаленно от здания сервера 108 торговца. Для того чтобы обеспечивать маршрутизацию транзакций к нескольким сетям обработки платежей, торговцу может потребоваться, чтобы TRSM 110 хоста торговца переводил зашифрованные данные в сообщении запроса авторизации. Например, может потребоваться перевести ключи в TRSM 110 хоста торговца для совместимости со стандартами PCI DSS, ограничивающими незащищенность ключей, ассоциированных с TRSM 106 устройства доступа. Когда хост-сервер 108 торговца выполнен с возможностью маршрутизации сообщений запроса авторизации нескольким сетям 112-116 обработки платежей, хост-сервер 108 торговца может переводить зашифрованные данные в Ключ Шифрования Зоны (ZEK), ассоциированный с конкретной сетью обработки платежей. Хост-сервер 108 торговца может определять, каким образом осуществлять маршрутизацию сообщения запроса авторизации на основании информации, которая содержится в сообщении запроса авторизации. Например, первые шесть цифр поля PAN, содержащие PAN, зашифрованный в соответствии со способом шифрования с сохранение формата, могут быть использованы хост-сервером 108 торговца для определения того, каким образом осуществлять маршрутизацию сообщения запроса авторизации.

[0051] Перевод посредством TRSM 110 хоста торговца может включать в себя дешифрование PIN и уязвимых данных в сообщении запроса авторизации, принятом от устройства 104 доступа, и повторное шифрование PIN и уязвимых данных, используя один или более Ключей Шифрования Зоны (ZEK). ZEK может быть ассоциирован с конкретной сетью обработки платежей. ZEK, как правило, является ключом, который совместно используется сетью обработки платежей и хост-сервером 108 торговца. Может потребоваться применение разных ZEK к PIN и уязвимым данным, например, для совместимости с PCI DSS. Перевод может выполняться TRSM 110 Хоста Торговца таким образом, что дешифрованный PIN и уязвимые данные никогда не раскрываются хост-серверу 108 торговца. Хост-сервер 108 торговца может передавать сообщение запроса авторизации, включающее в себя переведенный PIN и уязвимые данные, одной из сетей 112-116 обработки платежей, в которую должна быть выполнена маршрутизация сообщения запроса авторизации.

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

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

[0054] Следует понимать, что сервер, ассоциированный с сетью обработки платежей или иным объектом и ассоциированным TRSM, может быть использован вместо хост-сервера 108 торговца и TRSM 110 хоста торговца.

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

[0056] Внутри TRSM данные могут быть зашифрованы и/или дешифрованы, используя DUKPT и TDES. Следует иметь в виду, что другие системы распределения ключей (такие как мастер/сеансовый и фиксированный ключ) и/или другие алгоритмы шифрования (такие как RSA, DEA, ECIES, EAS, или другие алгоритмы шифрования) могут быть применены.

[0057] Фиг. 2 является иллюстративной блок-схемой для шифрования PIN и уязвимых данных в устройстве доступа и хосте торговца. На этапе 202 держатель карты может представить платежное устройство 102 устройству 104 доступа. На этапе 204 устройство 104 доступа может считать данные с платежного устройства 102, такие как данные дорожки, хранящиеся на магнитной ленте платежного устройства. Данные, считанные с платежного устройства 102, могут включать в себя уязвимые данные, такие как PAN, имя держателя карты, и дискреционные данные. На этапе 206 устройство 104 доступа может принять PIN, такой как PIN, введенный через интерфейс пользователя устройства 104 доступа.

[0058] На этапе 208 устройство 104 доступа может зашифровать PIN, используя первый ключ. Первый ключ может быть первым ключом конкретной транзакции, извлеченным из ключа, внедренного в устройство 104 доступа. На этапе 210 устройство 104 доступа может зашифровать уязвимые данные, используя второй ключ. Уязвимые данные могут включать в себя одно или более из следующего: PAN, имя держателя карты, дискреционные данные, адрес держателя карты, и любые другие уязвимые данные, принятые устройством 104 доступа. Второй ключ может быть вторым ключом конкретной транзакции, извлеченным из ключа, внедренного в устройство 104 доступа. На этапе 212 устройство 104 доступа может генерировать сообщение запроса авторизации, включающее в себя зашифрованный PIN и зашифрованные уязвимые данные, и передавать сообщение запроса авторизации хост-серверу, такому как хост-сервер 108 торговца.

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

[0060] Фиг. 3 является иллюстративной блок-схемой для перевода уязвимых данных на хосте. На этапе 302 хост, такой как