Система и способ для сквозного администрирования ключей
Изобретение относится к способу функционирования мобильного устройства, мобильному устройству и долговременному машиночитаемому носителю. Технический результат заключается в повышении безопасности криптографических ключей, хранящихся на мобильном устройстве и используемых в процессе транзакции. Способ содержит этапы, на которых: исполняют мобильное платежное приложение в пользовательском домене мобильного устройства, причем пользовательский домен содержит операционную среду, в которой мобильные приложения исполняются и доступ к ним осуществляется пользователем мобильного устройства, импортируют множество ключей шифрования для использования с мобильным платежным приложением в системный домен мобильного устройства, причем системный домен содержит более безопасную операционную среду, управляемую операционной системой мобильного устройства, шифруют платежную информацию мобильного платежного приложения в системном домене с использованием одного или более импортированных ключей во время исполнения мобильного платежного приложения в пользовательском домене, и передают зашифрованную платежную информацию продавцу. 3 н. и 17 з.п. ф-лы, 7 ил.
Перекрестная ссылка на родственную заявку
Настоящая заявка испрашивает преимущество и приоритет патентной заявки США № 15/218,842, поданной 25 июля 2016. Все раскрытие вышеуказанной заявки включено в настоящий документ посредством ссылки.
ОБЛАСТЬ ТЕХНИКИ
Примерные варианты осуществления, описанные здесь, в общем, относятся к транзакциям для оплаты товаров и/или услуг и, более конкретно, к повышению безопасности криптографических ключей, хранящихся на мобильном устройстве и используемых в процессе транзакции.
ПРЕДШЕСТВУЮЩИЙ УРОВЕНЬ ТЕХНИКИ
Облачные платежи поддерживают администрирование, генерацию и предоставление учетных данных (параметров доступа) цифрового платежа в мобильных устройствах, чтобы обеспечить возможности более простых и более безопасных опытов цифрового платежа. Системы облачного платежа были разработаны для перехода финансовой индустрии от учетных данных счета потребителя, хранящихся на традиционных платежных картах, к цифровым учетным данным, предоставленным мобильным устройствам. Оцифрованные учетные данные создают возможность для мобильного пользовательского устройства выполнять платежи посредством бесконтактных систем кассовых терминалов и посредством удаленных платежей, таких как встроенные в приложение (in-app) платежи. Оцифрованные учетные данные могут храниться в цифровых кошельках с использованием приложения кошелька, установленного на мобильном устройстве. Цифровой кошелек может быть предоставлен с конфиденциальными активами (ресурсами), такими как профиль карты и наборы ключей транзакции и администрирования.
Модели безопасности облачных платежей основываются на наборе контрмерах и технической структуре, включая различные элементы управления на протяжении жизненного цикла цифрового кошелька. Менеджмент рисков (Risk Management) выполняется на различных уровнях цифрового кошелька, мобильного устройства и во время онлайн авторизации транзакций в случае удаленного платежа. Отслеживание и анализ транзакций используются, чтобы обнаруживать незаконное использование цифрового кошелька и предпринимать действия, которые могут вызывать отклонение транзакции или даже временное приостановление действия оцифрованной карты, включенной в цифровой кошелек, или самого цифрового кошелька.
Как и любая основанная на программном обеспечении технология, облачные платежи являются целью атак различных типов, которые пытаются извлечь конфиденциальные активы или использовать цифровой кошелек незаконным образом. Дополнительно, финансовые мобильные приложения, такие как цифровые кошельки или приложения мобильного банка, используют методы безопасного кодирования, которые уже применяются некоторое время. В то время как умышленная запутанность и инструменты разработки манипулирования программным обеспечением могут дополнительно использоваться для повышения уровня безопасности мобильных приложений, все еще существует ряд пробелов в импорте, генерации и использовании ключей шифрования в пользовательском домене пользовательского устройства, что делает эти ключи уязвимыми для атаки.
В недавнее время, было сделан ряд попыток представить концепцию криптографии типа ʺпрозрачный ящикʺ (WBC) в стремлении обеспечить поддержку для безопасных криптографических операций в основанной на программном обеспечении среде. Однако, WBC требует дополнительных затрат и требует комплексного администрирования для администрирования белого ящика в течение жизненного цикла цифрового кошелька, такого как процесс обновления WBC.
КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ
Характеристики и преимущества примерных вариантов осуществления и способ, которым они осуществляются, станут более очевидными со ссылкой на следующее подробное описание в сочетании с прилагаемыми чертежами, на которых:
Фиг. 1 является диаграммой, иллюстрирующей маркерную платежную систему в соответствии с примерным вариантом осуществления.
Фиг. 2 является диаграммой, иллюстрирующей мобильную операционную среду, включающую в себя пользовательский домен и системный домен в соответствии с примерным вариантом осуществления.
Фиг. 3 является диаграммой, иллюстрирующей ключи шифрования, которые могут использоваться мобильным платежным приложением в соответствии с примерным вариантом осуществления.
Фиг. 4 является диаграммой, иллюстрирующей ключи шифрования, которые могут использоваться в системном домене мобильного устройства в соответствии с примерным вариантом осуществления.
Фиг. 5 является диаграммой, иллюстрирующей ключи шифрования, которые могут использоваться в системном домене мобильного устройства в соответствии с другим примерным вариантом осуществления.
Фиг. 6 является диаграммой, иллюстрирующей мобильное устройство в соответствии с примерным вариантом осуществления.
Фиг. 7 является диаграммой, иллюстрирующей способ платежа, выполняемый в нескольких доменах мобильного устройства в соответствии с примерным вариантом осуществления.
На всех чертежах и в подробном описании, если не описано иначе, одни и те же ссылочные позиции следует понимать как относящиеся к одним и тем же элементам, характеристикам и структурам. Относительный размер и изображение этих элементов могут быть преувеличены или скорректированы для ясности, иллюстрации и/или удобства.
ОСУЩЕСТВЛЕНИЕ ИЗОБРЕТЕНИЯ
В последующем описании изложены конкретные подробности, чтобы обеспечить полное понимание различных примерных вариантов осуществления. Следует учесть, что различные модификации вариантов осуществления будут очевидны специалистам в данной области техники, и общие принципы, определенные в настоящем документе, могут применяться к другим вариантам осуществления и приложениям без отклонения от сущности и объема изобретения. Более того, в следующем описании, многочисленные подробности изложены в целях объяснения. Однако специалисту в данной области техники следует понимать, что варианты осуществления могут быть осуществлены на практике без использования этих конкретных подробностей. В других примерах, хорошо известные структуры и процессы не показаны или не описаны, чтобы не затемнять описание ненужными подробностями. Таким образом, настоящее раскрытие не подразумевается ограниченным показанными вариантами осуществления, но должно соответствовать самому широкому объему, совместимому с принципами и признаками, раскрытыми в настоящем документе.
Как описано в настоящем документе, мобильное платежное приложение может использоваться для выполнения бесконтактных платежей, таких как через связь в ближней зоне (NFC), радиочастотную идентификацию (RFID) и тому подобное. При выполнении бесконтактной транзакции пользователь может приложить мобильное устройство к бесконтактному считывателю и приступить к транзакции с аутентификацией пользователя через устройство или POS (например, онлайн PIN или сигнатуру) или их оба или с использованием noCVM (например, для транзакций низкого значения). Также, мобильное платежное приложение может использоваться для выполнения удаленных платежей. При выполнении транзакции удаленного платежа, пользователь может делать покупки на онлайн-сайте продавца или использовать мобильное приложение и на некоторой стадии процесса может быть запрошен выполнить транзакцию. Соответственно, пользователь может использовать мобильное платежное приложение, такое как цифровой кошелек, для выполнения транзакции с использованием интернет-соединения (по сравнению с тем, что используется в физическом мире для бесконтактной процедуры).
Системы облачного платежа создают возможности для держателя карты загружать и устанавливать мобильные платежные приложения на мобильное устройство для использования в бесконтактных и удаленных транзакциях с продавцом. Держатель карты может ассоциировать один или более платежных счетов с мобильным платежным приложением и использовать мобильное устройство для транзакции через мобильное платежное приложение с продавцом. Во время транзакции, некоторое число ключей шифрования может использоваться устройством держателя карты, чтобы обезопасить конфиденциальную информацию платежного счета и другие платежные данные, передаваемые между мобильным устройством держателя карты и продавцом и/или платежной сетью.
Как результат первоначального проектирования систем облачных платежей, существует несколько пробелов в безопасности в сквозном администрировании ключей шифрования, используемых мобильным платежным приложением на устройстве держателя карты. Пробел, как описано в настоящем документе, возникает в точке, когда конфиденциальный ресурс, такой как ключ администрирования или ключ транзакции, каким-то образом раскрыт в пределах пользовательского домена пользовательского устройства, который является недоверительной средой, по сравнению с системным доменом пользовательского устройства, который управляется операционной системой (OS) и является более безопасным, чем пользовательский домен. В недавнее время, значительное количество усилий было предпринято для улучшения уровня безопасности мобильных устройств и введения новых характеристик безопасности через мобильную операционную систему. Примером улучшенной безопасности мобильного устройства является безопасное хранилище, такое как хранилище ключей. В качестве примера, хранилище ключей Android (Android Keystore), включенное в операционную систему Android, позволяет криптографическим ключам храниться в безопасном цифровом контейнере на пользовательском устройстве, чтобы сделать более сложным извлечение из него ключей. Как только ключи оказываются в хранилище ключей, они могут использоваться для криптографических операций. Более того, хранилище ключей может обеспечивать правила, которые ограничивают то, когда и как могут использоваться ключи, например, требуя аутентификацию пользователя для использования ключа или ограничивая ключи, подлежащие использованию только в конкретных криптографических режимах.
Согласно примерным вариантам осуществления, криптографические ключи, используемые во время процесса мобильного платежа или процесса бесконтактного платежа, могут быть дополнительно засекречены путем включения характеристик безопасности из мобильной операционной системы, например, из хранилища ключей Android в рамках сквозного администрирования ключей шифрования во время транзакции. Мобильное платежное приложение обычно хранит ключи в пользовательском домене по умолчанию. В противоположность этому, примерные варианты осуществления импортируют и задействуют ключи в системном домене, чтобы повысить характеристики безопасности мобильного устройства и уменьшить число пробелов в администрировании ключей. Например, ключи могут импортироваться в и исполняться доверительной средой исполнения или элементами аппаратных средств, доступными системному домену вместо пользовательского домена.
Как описано в настоящем документе, пользовательский домен относится к среде, в которой мобильное приложение, такое как цифровой кошелек, исполняет и действует в ответ на элементы управления от пользователя, а системный домен относится к более безопасной среде, которая находится под исключительным контролем операционной системы. Системный домен имеет доступ к функциям нижнего уровня, включая интерфейс с характеристиками безопасности, которые могут обеспечиваться доверительной средой исполнения или механизмами на основе аппаратных средств. Кроме того, существует строгая сегрегация (например, брандмауэр (шлюз безопасности)) между пользовательским доменом и системным доменом пользовательского устройства, обуславливающая ограничение доступа к системному домену. Обычно, взломщик будет нацелен на пользовательский домен, поскольку он проще и имеет значительно больше возможностей для доступа, при этом только продвинутые взломщики попытаются получить доступ к системному домену, который требует значительно более квалифицированного понимания, чтобы быть взломанным.
Ключи шифрования (т.е. ключи) могут импортироваться из другого устройства или генерироваться мобильным устройством. Ключи могут использоваться для выполнения различных операций, таких как шифрование, дешифрование, снабжение подписью (сигнатурами) и тому подобное, на данных, передаваемых между мобильным устройством и платежной сетью. Согласно различным примерным вариантам осуществления, импорт и генерация ключей наряду с операциями с использованием ключей могут выполняться в системном домене вместо пользовательского домена, тем самым препятствуя представлению ключей в пределах пользовательского домена. Кроме того, примерные варианты осуществления комбинируют функции, используемые для администрирования хранилища ключей в пределах операционной системы, чтобы повысить уровень безопасности ключей, так что отсутствует утечка ключей администрирования и ключей транзакции в пределах пользовательского домена. Соответственно, все из криптографических операций, начиная с импорта ключа безопасности до действительного использования ключа, могут выполняться в системном домене, с выгодой используя наиболее продвинутые методы, обеспечиваемые операционной системой, такие как доверительная среда исполнения или встроенный элемент безопасности, которые могут использоваться операционной системой ограниченным и управляемым образом.
Примерные варианты осуществления могут ограничивать типы операций, которые могут выполняться ключами в системном домене, например, системный домен может разрешать импорт, но не экспорт, разрешать шифрование, но не дешифрование (или наоборот) и использовать управление доступом для ограничения доступа к ключу, но с выгодой привлекать криптографические свойства ключа (такого как ассиметричный ключ), чтобы позволять любому шифровать данные с использованием общедоступного ключа, который является частью ключа. Кроме того, операции с привлечением ключей могут комбинироваться с дополнительными уровнями шифрования и дешифрования, чтобы реализовать дополнительные элементы управления. В качестве примера, транспортировка ключа или использование ключа могут быть приведены в надлежащее состояние после использования ключа перед дешифрованием этого ключа с использованием другого ключа, для которого определены правила доступа.
Фиг. 1 иллюстрирует маркерную платежную систему 100 в соответствии с примерным вариантом осуществления. Со ссылкой на фиг. 1, маркерная платежная система 100 включает в себя мобильное устройство 110, вычислительное устройство 120 продавца, вычислительное устройство 130 эмитента, сервер 140 мобильного приложения и сервер 150 администрирования, приобретателя 160 и платежную сеть 170. Следует также учесть, что маркерная платежная система 100 может включать в себя дополнительные непоказанные устройства, например, шлюз платежей и тому подобное, или одно или более из примерных устройств могут комбинироваться и встраиваться друг в друга. Следует также учесть, что маркерная платежная система 100 может включать в себя несколько мобильных устройств 110, вычислительных устройств 120 продавца, вычислительных устройств 130 эмитента, серверов 140 мобильного приложения, серверов 150 администрирования и вычислительное устройство 160 приобретателя.
Маркерная платежная система 100 может быть системой облачного платежа, которая поддерживает бесконтактные платежи и удаленные платежи с мобильного устройства 110 к продавцу 120. Например, мобильное устройство 110 может загружать и устанавливать мобильное платежное приложение из сервера 140 мобильного приложения. Платежное приложение может быть платежным приложением, ориентированным на эмитента, приложением, ориентированным на продавца, цифровым кошельком и тому подобным. В примере мобильного платежного приложения, ориентированного на эмитента, функциональная возможность платежа может быть интегрирована в мобильное устройство 110 в качестве части мобильного приложения эмитента (такого как эмитент 130), обеспечивающей мобильное приложение учетными данными для проведения платежных транзакций. В примере цифрового кошелька, функциональные возможности платежа могут быть интегрированы в качестве части цифрового кошелька, и сервер 140 мобильного приложения может быть провайдером кошелька, который способен оцифровывать одну или более платежных карт в один и тот же цифровой кошелек.
Пользователь может хранить маркированную (размеченную) информацию платежного счета одной или более платежных карт, ассоциированных с мобильным платежным приложением, установленным на мобильном устройстве 110. Мобильное платежное приложение может включать в себя MasterCard MasterPass, Google Wallet, Samsung Pay, Apple Pay и тому подобное. Информация платежного счета может включать в себя номер основного счета (PAN), дату истечения срока действия и тому подобное из платежных карт, обеспеченных эмитентом 130, и может размечаться и храниться на мобильном устройстве 110. В качестве другого примера, мобильное устройство 110 может хранить цифровой кошелек, имеющий сохраненную в нем размеченную платежную информацию из одной или более платежных карт, обеспеченных любым числом эмитентов, банков, финансовых объектов и тому подобного, и которые были ассоциированы с цифровым кошельком пользователем. В результате, мобильное устройство 110 можно трансформировать в коммерческое устройство, способное совершать платежи продавцу 120 как удаленно, так и лично.
Сервер 150 администрирования может включать в себя множество устройств, модулей, программ, программного обеспечения и тому подобного. Например, сервер 150 администрирования может управляться финансовым объектом, таким как MasterCard Incorporated, и может включать в себя систему администрирования учетных данных (CMS), систему задействования счета (AES), систему администрирования транзакций (TMS), защищенное хранилище маркеров и тому подобное. В этих примерах, сервер 150 администрирования может включать в себя или может быть соединен с устройством обеспечения службы маркеров. Устройство обеспечения службы маркеров может генерировать маркеры вместо информации платежной карты и хранить и поддерживать отображение или таблицу информации, необходимой для преобразования маркированной (размеченной) платежной информации (такой как размеченный PAN) в действительную платежную информацию. Согласно различным примерным вариантам осуществления, сервер 150 администрирования может хранить различные ключи шифрования для использования с мобильным платежным приложением, хранящимся на мобильном устройстве 110, чтобы использовать во время процесса платежа или транзакции. Например, ключи могут включать в себя первичные ключи для маркеров, ключи сеансов для использования в транзакциях, ключи администрирования и тому подобное. Ключи могут переноситься из сервера 150 администрирования на мобильное устройство перед или во время транзакции.
В примере фиг. 1, мобильное платежное приложение, установленное на мобильном устройстве 110, обеспечивает внешний интерфейс держателю карты и администрирует пользовательский опыт от подписки на услугу платежа до проведения транзакций с мобильным устройством 110, и администрирует функции, такие как изменение персонального идентификационного номера (PIN). Сервер 140 мобильного приложения обеспечивает внешний интерфейс держателю карты и администрирует пользовательский счет держателя карты и может интегрировать облачные оцифрованные службы для оцифровки платежных карт в мобильное платежное приложение.
Согласно различным примерным вариантам осуществления, введено множество усовершенствований маркерной платежной системы 100 в стремлении дополнительно повысить безопасность платежных транзакций между мобильным устройством 110 и продавцом 120. Первая волна усовершенствований выполнена для импортирования, хранения и использования ключей шифрования мобильным устройством 110 путем включения импортирования ключей, хранения ключей и операций с ключами в системный домен мобильного устройства 110. Вторая волна усовершенствований выполнена путем расширения изменений ключей для системы администрирования платежных данных сервера 150 администрирования. Третья волна усовершенствований выполнена путем перемещения криптограмм транзакций системы администрирования транзакций сервера 150 администрирования в отличающийся алгоритм шифрования, и четвертая волна изменений выполнена путем осуществления изменений в мобильной операционной системе мобильного устройства 110.
Сервер 150 администрирования может включать в себя некоторое число различных систем. Например, система задействования счета может обеспечивать службы для проверки платежной карты и пригодности устройства для служб облачного платежа, выполнять идентификацию и верификацию, чтобы аутентифицировать держателя карты, оцифровывать платежные карты и координировать администрирование жизненного цикла. Защищенное хранилище маркеров может поддерживать таблицу отображения маркера на PAN счета. Оцифрованные платежные карты могут быть предоставлены в систему администрирования учетных данных. Система администрирования учетных данных может хранить первичные ключи для маркера и генерировать ключи сеанса во время транзакции, которые могут быть преобразованы в учетные данные транзакции. Система администрирования учетных данных может комбинировать ключи сеанса с мобильным PIN, чтобы создать учетные данные транзакции и предоставить их мобильному платежному приложению, чтобы задействовать мобильное платежное приложение выполнить транзакцию. Система администрирования транзакций может обрабатывать транзакции, верифицировать криптограммы приложений, чтобы аутентифицировать используемые учетные данные и верифицировать, что был введен корректный мобильный PIN.
Пользователь мобильного устройства 110 может попытаться выполнить транзакцию с продавцом 120. Например, мобильное устройство 110 может совершить платеж с использованием бесконтактных или удаленных платежных возможностей, обеспечиваемых цифровым кошельком или другим мобильным платежным приложением. Когда продавец 120 принимает платежные данные от мобильного устройства 110, продавец 120 может передать платежные данные приобретателю 160. Приобретатель 160 может передать платежные данные платежной сети 170 для обработки. Если платежные данные включают в себя маркированную (размеченную) платежную информацию, платежная сеть 170 может передать размеченную платежную информацию эмитенту 130 и/или серверу 150 администрирования для перевода в действительную платежную информацию. Также, эмитент 130 может верифицировать, имеет ли платежный счет, соответствующий платежным данным, достаточные средства для покрытия сделки с продавцом 120. Результат авторизации может быть отправлен обратно продавцу 120 через обратный тракт.
Хотя это не показано на фиг. 1, маркерная платежная система 100 может дополнительно включать в себя службу удаленного уведомления, такую как Google Cloud Messaging, Apple Push Notification Service, Microsoft Push Notification Service и тому подобное. Служба удаленного уведомления может осуществлять связь с мобильным платежным приложением и обеспечивать различные уведомления.
Фиг. 2 иллюстрирует мобильную операционную среду, включающую в себя пользовательский домен 200 и системный домен 300 в соответствии с примерным вариантом осуществления. Со ссылкой на фиг. 2, пользовательский домен 200 является операционной средой, в которой может действовать мобильное приложение, такое как мобильное платежное приложение, приложение продавца, цифровой кошелек и тому подобное. Пользовательский домен 200 является доменом, в котором пользователь может взаимодействовать с различными приложениями, работающими на мобильном устройстве. Когда несколько мобильных приложений действуют в пользовательском домене 200, операционная система мобильного устройства может обеспечить некоторый уровень ʺигры в песочницеʺ (механизма обеспечения безопасности на основе изоляции) между приложениями в пользовательском домене 200, чтобы управлять и/или ограничивать область, к которой мобильное приложение может получить доступ.
Системный домен 300 является более безопасной операционной средой, которая может находиться под исключительным контролем операционной системы мобильного устройства. В различных примерах, пользователю или неавторизованным мобильным приложениям не разрешено осуществлять доступ к данным в пределах системного домена 300. Системный домен 300 может иметь доступ к функциям нижнего уровня и может быть интерфейсом с различными характеристиками безопасности, такими как доверительная среда исполнения (TEE) 316, механизмы 314 на основе аппаратных средств (например, элементы безопасности, хранилище, криптопроцессоры) и тому подобное. Согласно различным примерным вариантам осуществления, хранилище 310 ключей включено в пределы системного домена 300 и включает в себя одну или более записей 312 ключей, а также TEE 316 и механизмы 314 на основе аппаратных средств. Хранилище 310 ключей может отвечать за хранение и поддержку криптографических ключей, имеющих соответствующие записи 312 и идентификацию их владельцев. Ключи могут импортироваться из пользовательского домена 200 в хранилище 310 ключей системного домена 300. Примером хранилища ключей является хранилище ключей Android, включенное в мобильную операционную систему Android, спроектированную Google. В некоторых примерах, ключ может экспортироваться из системного домена 300 в пользовательский домен 200, например, в случае, когда ключ ограничен до конкретного типа операции обработки и/или условий в пределах пользовательского домена 200.
В примерных вариантах осуществления существует строгая сегрегация, например, брандмауэр (шлюз безопасности), между пользовательским доменом 200 и системным доменом 300. В результате, доступ к системному домену 300 очень ограничен. Например, системный домен 300 может находиться под исключительным контролем операционной системы, что может препятствовать доступу приложений, устройств и пользователей к системному домену 300 и доступу к ключам шифрования, хранящимся в системном домене 300. Также, операционная система может предотвращать операции того типа, который может выполняться в системном домене 300. Ввиду стойкости безопасности системного домена 300, взломщик обычно будет нацеливаться на пользовательский домен 200, в то время как только самые продвинутые взломщики могут пытаться получить доступ к системному домену 300. Кроме того, доступ к механизмам безопасности, таким как TEE 316 и механизмы 314 на основе аппаратных средств, используемым этим системным доменом 300, может требовать еще больше навыков, чтобы использовать их или даже взломать.
В примере фиг. 2, пользовательский домен 200 имеет мобильное платежное приложение 210, установленное и исполняемое в нем. Например, мобильное платежное приложение 210 может быть цифровым кошельком, платежным приложением продавца, платежным приложением, ориентированным на эмитента, и тому подобным. Пользовательский домен 200 может также включать в себя другие мобильные приложения 220, которые могут исполняться в нем. Мобильное платежное приложение 210 включает в себя множество процессов (P1, P2, Pn, и т.д.) 215. В некотором примере, мобильное платежное приложение 210 может также включать в себя компонент криптографии типа ʺпрозрачный ящикʺ (WBC), который действует в пользовательском домене 200. Мобильное платежное приложение 210 может хранить информацию в базе данных, действующей в среде пользовательского домена 200. Согласно различным примерным вариантам осуществления, мобильное платежное приложение 210 может использовать хранилище 310 ключей во время обработки платежа и создавать записи 312 хранилища ключей, которые могут использоваться во время обработки платежа. Например, каждая запись в хранилище 310 ключей может быть ассоциирована с ключом (и его ярлыком) и параметрами, такими как алгоритм шифрования (такой как AES, RSA, ECC…), правила доступа и криптографические функции, разрешенные в системном домене 300 (такие как шифрование, дешифрование, снабжение подписью и тому подобное).
Хранилище 310 ключей может действовать в системном домене 300 и может получать выгоду в безопасности из доверительной среды 316 исполнения и/или доступных компонентов 314 аппаратных средств. В этом примере, существует первый уровень сегрегации между приложениями в пользовательском домене 200. В дополнение к этому, существует другой уровень сегрегации между пользовательским доменом 200 и системным доменом 300. В результате, пользовательский домен 200 и системный домен 300 могут действовать как слои лука или матрешка, где каждая кукла формирует другой уровень защиты. В этом примере, данные, хранящиеся в системном домене 300, имеют больше уровней безопасности, чем данные, хранящиеся в пользовательском домене 200. В некоторых примерах, вызовы в хранилище 310 ключей могут не позволять вызывающему выполнять последовательность операций в компоненте записи 312 хранилища ключей в системном домене 300 и только возвращать конечный результат из системного домена 300 в пользовательский домен 200. В качестве примера, когда криптографическая операция выполняется в системном домене 300, ответ на нее может быть отправлен обратно на пользовательский домен 200 и может потенциально представляться взломщику, нацеленному на пользовательский домен 200. Вследствие этого, хранилище 310 ключей может быть модулем безопасности на аппаратных средствах, который способен выполнять только одну операцию в каждый момент времени без способности хранить любые временные результаты или значения.
Согласно различным аспектам, системный домен 300 может быть подчиненным пользовательскому домену 200. В примере фиг. 2, бизнес-логика кошелька 210 (включая мобильное платежное приложение) исполняется в пользовательском домене 200. Однако криптографические операции могут выполняться в системном домене 300. Вследствие этого, криптографические операции могут выполняться в системном домене 300 в результате вызова интерфейса программирования приложения (API) или тому подобного из пользовательского домена 200 в системный домен 300. Здесь, например, процесс (P2) кошелька 210, исполняющийся в пользовательском домене 200, вызывает системный домен 300 с использованием fn(KS, данные), где fn() является криптографической функцией, KS является ярлыком хранилища 310 ключей, и данные являются некоторыми данными, подлежащими обработке. Далее, ответ (resp) переносится из системного домена 300 в пользовательский домен 200. В этом примере, хранилище 310 ключей является подчиненным процессам, действующим в пользовательском домене 200, и его можно вызвать в случае необходимости процессами, включенными в кошелек 210. Ключи, включенные в хранилище 310 ключей, могут генерироваться хранилищем 310 ключей в ответ на вызов из пользовательского домена 200 или могут импортироваться в хранилище 310 ключей из пользовательского домена 200. Согласно различным аспектам, ключи могут быть зашифрованными во время нахождения в пользовательском домене 200 (либо до импортирования из пользовательского домена 200, либо после экспортирования в пользовательский домен из системного домена) и поэтому дополнительно защищены.
Фиг. 3 иллюстрирует ключи шифрования, которые могут использоваться мобильным платежным приложением 210 в соответствии с примерным вариантом осуществления. Со ссылкой на фиг. 3, мобильное платежное приложение 210 включает в себя множество ключей, импортированных в пользовательский домен 200 или сгенерированных в пользовательском домене 200, и используемых в пользовательском домене 200, при этом системный домен 300 пуст. В этом примере, мобильное платежное приложение 210 может использовать множество ключей 350 шифрования во время процесса оплаты. В примерах в настоящем документе, термин (MK) относится к мобильному ключу, (MSK) относится к мобильному ключу сеанса, (ICC) ключ относится к ключу карты с интегральной схемой, и (LDE) ключ относится к ключу шифрования локальной базы данных. Также, AES, RSA, 3DES и тому подобное относятся к типам шифрования в данной области техники.
Системы облачных платежей могут использовать различные службы безопасности, исполняемые в пользовательском домене 200 при использовании мобильного платежного приложения 210. Примеры служб шифрования облачных платежей, показанных на фиг. 3, включают в себя генерацию случайного ключа (RGK) мобильным платежным приложением 210 и экспорт RGK в систему администрирования учетных данных (CMS), где RGK может быть зашифрован с использованием открытого ключа RSA, обеспеченного CMS. Например, CMS может быть включена в или соединена с сервером 150 администрирования, показанным на фиг. 1. Службы шифрования облачных платежей могут включать в себя мобильные ключи, такие как мобильный ключ кода аутентификации сообщения (MAC), ключ транспортировки (TK) и ключ шифрования данных (DEK), которые могут доставляться из CMS и шифроваться посредством RGK, мобильные ключи сеансов (MAC и TK - AES ключи), сгенерированные мобильным платежным приложением 210 с использованием мобильных ключей (MAC и TK) и информации сеанса в качестве диверсификатора, мобильные ключи сеансов (MAC и TK), используемые мобильным платежным приложением в качестве части протокола сообщения между мобильным платежным приложением и CMS, мобильный ключ (DEK), который может использоваться для защиты конфиденциальных ресурсов в профиле карты (ICC KEK), или набор ключей (ключей сеанса и ключей одноразового использования) в контейнере ключей, предоставленном CMS, ключ (ключ AES) шифрования локальной базы данных (LDE), сгенерированный мобильным платежным приложением и используемый для безопасного хранения данных (шифрования и дешифрования), ключ одноразового использования (ключ 3DES) для преобразования ключа сеанса (ключа 3DES) с использованием (заменителя) мобильного PIN. Системы облачного платежа могут также выполнять генерацию криптограмм AC/CVC с использованием ключей сеанса (ключа 3DES), дешифрование секретного ключа ICC с использованием ICC KEK (ключа AES) и генерацию сигнатуры CDA с использованием пары ключей ICC (ключа RSA).
Однако, на фиг. 3, ключи шифрования импортируются в и используются мобильным платежным приложением 210 в пределах пользовательского домена 200. В результате, ключи могут быть объектом атаки взломщика, который получает доступ к пользовательскому домену 200. Фиг. 4 иллюстрирует ключи шифрования, которые могут использоваться в системном домене 300 в соответствии с примерным вариантом осуществления. В примере фиг. 4, дополнительные улучшения безопасности поддерживаются в пределах мобильного устройства по сравнению с системой согласно фиг. 3. Операционная система мобильного устройства может использоваться для управления системным доменом 300 на основе действий, которые происходят во время исполнения мобильного платежного приложения в пользовательском домене 200.
Со ссылкой на фиг. 4, согласно различным примерным вариантам осуществления, мобильные ключи 410 (MAC, TK и DEK - ключи AES) могут импортироваться в и использоваться хранилищем 310 ключей в пределах системного домена 300 и могут иметь стандартное управление доступом устройства. В этом примере, стандартное управление доступом устройства может не быть связано с аутентификацией пользователя. Например, мобильные ключи 410 могут импортироваться из CMS, соединенной с или включенной в сервер 150 администрирования согласно фиг. 1. В дополнение к этому, ресурсы, зашифрованные мобильным ключом (DEK), могут администрироваться в хранилище 310 ключей системного домена 300.
В этом примере, мобильное платежное приложение может использовать хранилище 310 ключей в системном домене 300, чтобы хранить мобильные ключи 410 и выполнять криптографические операции с использованием мобильных ключей 410. Мобильное платежное приложение может принимать мобильные ключи 410, зашифрованные ключом RGK. В этих примерах, мобильное платежное приложение может создавать запись хранилища ключей MAC с параметрами, такими как алгоритм шифрования, представляющий собой AES, управление доступом, представляющее собой стандартное устройство без аутентификации пользователя, и функции, ограниченные подписанием (генерация HMAC, используемая для извлечения мобильных ключей сеансов) и ʺподписьюʺ (валидация MAC) в пределах системного домена 300. Мобильное платежное приложение может также создавать запись хранилища ключей TK с параметрами, такими как алгоритм шифрования, представляющий собой AES, причем управление доступом представляет собой стандартное устройство без аутентификации пользователя, и функции ограничены подписанием (генерация HMAC, используемая для извлечения мобильных ключей сеансов) и дешифрованием. Мобильное платежное приложение может также создавать запись хранилища ключей DEK с параметрами, такими как алгоритм шифрования, представляющий собой AES, причем управление доступом представляет собой стандартное устройство без аутентификации пользователя, и функции ограничены дешифрованием и шифрованием.
Мобильные ключи MAC, TK и DEK 410 могут импортироваться (в незашифрованном виде) в хранилище 310 ключей. Мобильный ключ MAC (ksMkMac) может использоваться, чтобы валидировать MAC, вычисленный по сообщению удаленного уведомления, отправленному CMS при доставке информации о сеансе, подлежащем установлению мобильным платежным приложением. Также, мобильному ключу MAC (ksMkMac) может быть разрешено генерировать мобильные ключи MAC сеансов, которые возвращаются в мобильное платежное приложение 210, исполняющееся в пользовательском домене 200 во время процесса оплаты. Мобильный ключ TK (ksMkTk) может использоваться для дешифрования зашифрованного содержимого сообщения удаленного уведомления, отправленного CMS при доставке информации о сеансе, подлежащем установлению мобильным платежным приложением. Также, мобильный ключ TK (ksMkTk) может использоваться для генерации мобильных ключей TK сеансов, которые возвращаются в пользовательский домен 200. Мобильному ключу DEK может быть разрешено дешифровывать и/или зашифровывать данные на эксплуатационном уровне.
В примере фиг. 4, дешифрование мобильных ключей 410 может выполняться мобильным платежным приложением, исполняющимся в пользовательском домене 200, но мобильные ключи 410 могут немедленно импортироваться в хранилище 310 ключей системного домена 300, идентифицированное с использованием ярлыков KS. Когда процесс импорта завершен, мобильные ключи 410 могут уничтожаться или стираться из пользовательского домена 200. С этого момента все криптографические операции могут выполняться с использованием мобильных ключей (MAC, TK и DEK) 410 с использованием хранилища 310 ключей в системном домене 300. Когда мобильный ключ MAC и мобильный ключ TK используются для генерации мобильных ключей сеансов в системном домене 300, мобильные ключи сеансов могут быть возвращены в мобильное платежное приложение 210 пользовательского домена 200. Криптографические операции с использованием мобильных ключей сеансов могут выполняться в пользовательском домене 200 и вследствие этого могут потенциально быть открыты взломщику, нацеленному на пользовательский домен 200. Однако мобильный ключ сеанса может быть действительным только для одного сеанса между мобильным платежным приложением и CMS с использованием идентификатора сеанса, определенного CMS. Кроме того, при интегрировании списка улучшений безопасности, описанных в настоящем документе, роль мобильных ключей сеансов может стать менее критичной, и вследствие этого, даже если взломщику удается нацелиться на мобильные ключи сеансов, потребовалось бы преодолеть дополнительные контрмеры безопасности, чтобы получить доступ к конфиденциальным ресурсам, таким как ключи транзакции (зашифрованные мобильным ключом DEK).
Согласно различным примерным вариантам осуществления, ключи 420 LDE могут генерироваться и использоваться в хранилище 310 ключей системного домена 300. Например, мобильное платежное приложение может делегировать генерацию ключей 420 LDE хранилищу 310 ключей, и все криптографические операции могут выполняться в системном домене 300 вместо реализации процесса для определения ключей 420 LDE и выполнения всех операций в пользовательском домене 200. Ключи 420 LDE могут случайно генерироваться хранилищем 310 ключей в системном домене 300. С этого момента все криптографические операции, совершаемые с использованием ключей 420 LDE, могут выполняться с использованием хранилища 310 ключей в системном домене 300 без какого-либо открытия ключей 420 LDE пользовательскому домену 200 (т.е. мобильному платежному приложению в пользовательском домене 200). Ключи 420 LDE могут включать в себя ключ LDE с управлением доступом пользователя (ключ LDEUSR). Ключ LDEUSR может случайно генерироваться хранилищем 310 ключей и может иметь общедоступный ключ, который обеспечен мобильному платежному приложению, работающему в пользовательском домене 200. Ключ LDEUSR может использоваться для дешифровки данных, которые хранятся в локальной базе данных, используемой мобильным платежным приложением. Процесс шифрования может выполняться в пользовательском домене 200 мобильным платежным приложением с использованием открытого ключа без требования какого-либо доступа к характеристике шифрования хранилища 310 ключей.
Согласно различным примерным вариантам осуществления, пара 430 ключей ICC может импортироваться в и использоваться в хранилище 310 ключей системного домена 300. Мобильное платежное приложение может принимать пару 430 ключей ICC и ее компоненты (p, q, dp, dq и u) из CMS в качестве части профиля карты держателя карты, соответствующего мобильному платежному приложению. Компоненты, требуемые для восстановления пары ключей, могут быть зашифрованы ключом ICC KEK. ICC KEK может быть частью профиля карты держателя карты и может быть зашифрован мобильным ключом (DEK). Мобильное платежное приложение может использовать хранилище 310 ключей, чтобы хранить пару 430 ключей ICC и выполнять генерацию сигнатуры CDA в системном домене 300.
Системы облачного платежа могут намеренно интегрировать концепцию аутентификации локальных данных (LDA), которая является вариантом CDA, чтобы предотвратить любое неправильное использование пары 430 ключей ICC, чтобы выполнить успешные офлайн транзакции. Дополнительный уровень защиты пары 430 ключей ICC особенно важен в среде, такой как переходная, которая пытается предотвратить любой неконтролируемый экспорт или утечку конфиденциальных ресурсов, которые могут быть использованы в модели, поддерживающей концепцию отложенной онлайн авторизации (то есть, криптограмма транзакции не подтверждается в реальном времени в момент времени транзакции). При использовании перехода, действительная сигнатура CDA может быть использована (даже с неверной криптограммой транзакции), чтобы пройти через шлюзы перехода, прежде чем PAN, ассоциированный с оцифрованной картой, будет внесен в черный список в результате неуспеха во время подтверждения криптограмм транзакции.
Мобильное платежное приложение может создавать запись в хранилище ключей пары ключей ICC с параметрами, такими как алгоритм шифрования, представляющий собой RSA, причем управление доступом представляет собой стандартное устройство без аутентификации пользователя, и функция ограничена подписанием (генерация CDA). Мобильное платежное приложение может использовать мобильный ключ DEK, чтобы дешифровывать ICC KEK. Дешифрование каждого компонента CRT с использованием ICC KEK может выполняться в пользовательском домене, и пара 430 ключей ICC может немедленно импортироваться в хранилище 310 ключей. Как только процесс импорта завершен, компоненты ICC KEK и CRT могут быть удалены из пользовательского домена 200. С этого момента криптографическая операция (которая генерирует сигнатуру CDA), совершаемая с использованием пары 430 ключей ICC, может выполняться с использованием хранилища 310 ключей в системном домене 300.
Дополнительная запись хранилища 310 ключей (ключ RSA) может использоваться, чтобы обеспечить средство для усиления хранения конкретным управлением доступом к ключам. С использованием этого усовершенствования, доступ к ключам UMD может требовать аутентификации держателя карты с использованием мобильного устройства (как при использовании устройства CDCVM в качестве части процесса разблокирования устройства с использованием отпечатка пальца). Этот опциональный признак добавляет уровень шифрования к ключам UMD сеанса, чтобы обусловить доступ к ключам UMD для успешной аутентификации держателя карты на мобильном устройстве (с использованием устройства CDCVM). Кошелек может создавать запись в хранилище ключей ключа LDEUSR с параметрами, такими как алгоритм, представляющий собой RSA (или ECC), управление доступом, представляющее собой аутентификацию пользователя (разблокирование устройства), и функция, ограниченная дешифрованием. Ключ LDEUSR может случайно генерироваться хранилищем 310 ключей в системном домене 300. Компонент общедоступного ключа может извлекаться и храниться в пользовательском домене 200.
Мобильное платежное приложение может хранить зашифрованные ключи MD сеанса (SK_xx_MD) и зашифрованное значение IDN. Зашифрованные ключи UMD одноразового использования (SUK_xx_UMD) (зашифрованные мобильным ключом DEK) могут быть зашифрованы мобильным платежным приложением с использованием открытого компонента RSA (Pk) до хранения в местной зашифрованной базе данных. Здесь, общедоступный ключ может быть доступным в пользовательском домене 200 и может использоваться в любое время мобильным платежным приложением без какого-либо управления доступом пользователя. Доступ к ключам UMD одноразового использования в момент времени транзакции может быть защищен правилами управления доступом, ассоциированными с секретным компонентом RSA (Sk), так как ключи UMD могут быть дешифрованы в системном домене 300 с использованием секретного компонента RSA (Sk), только если успешная аутентификация держателя карты была выполнена на уровне мобильного устройства (устройства CDCVM). Второе дешифрование может выполняться с использованием мобильного ключа DEK, чтобы извлечь ресурсы, защищенные мобильным ключом DEK, таким как ключи UMD и MD и значение IDN.
Фиг. 5 иллюстрирует ключи шифрования, которые могут использоваться в системном домене 300 в соответствии с другим примерным вариантом осуществления. В этом примере, CMS сетевого сервера 150 администрирования может быть обновлена согласно различным примерным вариантам осуществления, и вторая волна усовершенствований может быть реализована в маркерной платежной системе 100 фиг. 1. Со ссылкой на фиг. 5, заново созданный мобильный ключ для мобильного платежного приложения согласно различным примерным вариантам осуществления (мобильный ключ DEKUSR 510) импортируется в хранилище 310 ключей системного домена 300 и используется, чтобы шифровать и дешифровать данные во время исполнения мобильного платежного приложения. Аутентификация пользователя может запрашиваться, чтобы использовать мобильный ключ DEKUSR 510.
В этом примере, связь между мобильным платежным приложением и CMS может использовать протокол сообщений, в котором данные защищены с использованием мобильных ключей сеансов (MAC и TK) 410 на уровне транспортировки и мобильного ключа (DEK) 410 для шифрования при эксплуатации. Были проанализированы несколько опций, чтобы интегрировать концепцию шифрования при эксплуатации, связанного с управлением доступом пользователя. Решения с использованием ассиметричной криптографии были отброшены в результате потенциального влияния на выполнение системы с ограниченной выгодой, так как импорт ключа безопасности не определен в настоящее время для информационного обмена с хранилищем ключей. Согласно различным примерным вариантам осуществления, при использовании этого усовершенствования безопасности вводится мобильный ключ DEKUSR 510, чтобы переместить интеграцию управления доступом пользователя на уровень CMS, тем самым усиливая правила для управления доступом предварительно в процессе предоставления. В результате введения мобильного ключа DEKUSR 510, ключ 420 LDEUSR может не использоваться, и ассоциированный процесс может больше не использоваться на уровне мобильного платежного приложения. В примере фиг. 5, мобильное платежное приложение может создавать запись в хранилище 310 ключей для мобильного ключа DEKUSR 510, в котором алгоритм шифрования установлен в AES, управление доступом установлено на аутентификацию пользователя (разблокирование устройства), и функции установлены для шифрования и дешифрования.
В примере фиг. 5, имеется опциональное использование для криптографии типа ʺпрозрачный ящикʺ (WBC) для генерации криптограммы. Эмитент или провайдер кошелька (т.е., провайдер мобильного платежного приложения), который желает расширить сквозную защиту ключей сеанса транзакции, может рассматривать WBC в качестве опции для улучшения уровня безопасности системы облачного платежа и использовать его собственную настроенную версию пакета разработки программного обеспечения (SDK). Целью является снизить открытие ключей транзакции в пользовательском домене 200 и получение выгоды от WBC, исполняемой в пользовательском домене 200, чтобы дешифровать ключи и сгенерировать криптограммы транзакций с использованием процесса, реализуемого в компоненте WBC. В этом случае, CMS потребовалось бы знать значение ключа транспортировки (AES), совместно используемого между компонентом WBC кошелька и CMS. Настроенная версия CMS-D потребует шифровать ключи сеанса транзакции, и эти зашифрованные ключи должны доставляться в кошелек с использованием усовершенствованных механизмов, описанных в настоящем документе. В этом примере, компонент WBC в кошельке может реализовывать последовательность операций с использованием единичного вызова в компонент WBC, чтобы дешифровать зашифрованные ключи сеанса транзакции и поддерживать динамическое значение ключей сеанса транзакции и генерировать криптограммы транзакции с использованием ключей сеанса транзакции. В этом случае, дополнительное шифрование с использованием ключа WBC выполняется при помощи CMS, чтобы подготовить данные, которые будут использоваться компонентом WBC кошелька. Каждая запись может быть сохранена и зашифрована ключом 420 LDE. Поддержка WBC может быть обеспечена поставщиками WBC в качестве части выпущенного настроенного SDK, в то время как приоритетом для усовершенствований безопасности может быть хранилище 310 ключей (то есть, стандартная характеристика операционной системы мобильного устройства).
Третья волна усовершенствований безопасности может быть выполнена для системы администрирования транзакций (TMS), включенной в или соединенной с сервером 150 администрирования. В некоторых случаях, хранилище 310 ключей может не включать в себя 3DES в качестве части списка поддерживаемых алгоритмов. В результате, может быть затруднительным предоставить сквозное решение для администрирования ключей с использованием хранилища ключей, которое способно генерировать криптограммы транзакции из хранилища ключей (системного домена 300) вместо генерации криптограмм транзакции из пользовательского домена 200 с использованием ключей сеанса транзакции, которые потенциально открыты взломщику, нацеленному на пользовательский домен 200. Согласно различным примерным вариантам осуществления, другим путем решения проблемы является использование поддержки AES, как определено в хранилище ключей Android, и перемещение от 3DES к AES генерации криптограмм транзакции (на уровне кошелька) и валидации (на уровне TMS). При использовании AES в качестве алгоритма для администрирования криптограмм транзакции, следующие операции предполагаются оставаться неизменными, чтобы избежать дополнительных изменений в CMS, отвечающей за подготовку данных: алгоритм, используемый для генерации значения IVCVC3 магнитной полосы, остается неизменным и использует MAC с ключом 3DES (CMK_CL_UMD), алгоритм для генерации ключа сеанса (SK_CL_MD или SK_CL_UMD) с использованием первичного ключа карты (CMK_CL_MD или CMK_CL_UMD), и ATC в качестве диверсификатора остается неизменным и использует способ EMV CSK с ключами 3DES без какой-либо настройки извлеченного ключа для контроля по четности, и длина ключей сеанса транзакции (SK_xx_MD и SK_xx_UMD) составляет 16 байт и остается неизменной при использовании AES (16 байт) вместо 3DES (с использованием двух ключей из 8 байт). Процесс генерации (и подтверждения) криптограммы, который используется для EMV и для транзакции с магнитной полосой, гармонизируется, и один общий процесс с использованием алгоритма MAC с использованием 16-байтного блочного шифра (AES) может использоваться для генерации AC или CVC3. Различие между EMV и транзакцией с магнитной полосой состоит в списке данных, которые используются для определения сообщения (MSG), подлежащего обработке с помощью MAC. Подготовка сообщения (включая процесс заполнения) выполняется в пользовательском домене 200, в то время как генерация криптограммы выполняется с использованием хранилища ключей в системном домене 300 без какого-либо открытия ключей транзакции пользовательскому домену 200. Полная сила решения будет достигнута, когда доступен импорт ключа безопасности ключей транзакции в хранилище ключей. При валидации транзакций, TMS потребуется идентифицировать кошельки (например, с использованием конкретного диапазона PAN), что поддерживает AES вместо 3DES для генерации криптограммы. Аппаратный модуль безопасности, используемый TMS, потребуется обновить для поддержки валидации MAC с использованием алгоритма MAC, использующего 16-байтного блочного шифра (AES), вместо использования алгоритма MAC, использующего 8-байтного блочного шифра (3DES).
Четвертая волна усовершенствований может быть выполнена с использованием обновленной мобильной операционной системы. Например, при использовании хранилища ключей Android, как определено в Android MarshMallow (Android M - API 23+), ключ может случайно генерироваться хранилищем ключей или импортироваться в хранилище ключей. При использовании характеристики импорта, ключ доступен в незашифрованном виде в пользовательском домене 200 до его загрузки в хранилище ключей в системном домене 300. Ключи, которые пригодны для импорта в хранилище ключей (такие как мобильные ключи или ключи транзакции), потенциально открыты взломщику, нацеленному на пользовательский домен, и сквозное администрирование ключей не может быть развернуто в настоящее время между CMS-D и хранилищем ключей Android в системном домене 300. Согласно различным примерным вариантам осуществления, импорт ключа безопасности может поддерживаться с использованием механизма, который определен источником операционной системы. Если таковое требуется, источник сервера 150 администрирования, такой как MasterCard Incorporated, может обеспечить некоторые опции для процесса, подлежащего использованию, но ожидается настройка их процессов (таких как предоставление ключей, совершаемое CMS) для решения, которое ожидается сделать доступным через новый API.
Фиг. 6 иллюстрирует мобильное устройство 600 в соответствии с примерным вариантом осуществления. Со ссылкой на фиг. 6, мобильное устройство 600 включает в себя процессор 610, блок 620 ввода, блок 630 импорта и передатчик 640. В качестве неограничивающего примера, мобильное устройство 600 может быть мобильным телефоном, планшетом, ноутбуком, фаблетом, персональным компьютером, электронным прибором, телевизором и тому подобным. Также, мобильное устройство 600 может включать в себя мобильную операционную систему или операционную систему, реализующую один или более примерных вариантов осуществления, описанных в настоящем документе. Мобильное устройство 600 может соответствовать мобильному устройству 110, показанному на фиг. 1. Мобильное устройство 600 может также включать в себя один или более компонентов, которые не показаны на фиг. 6, например, приемник, сетевой интерфейс, блок вывода и тому подобное.
Согласно различным примерам, мобильное устройство 600 может загружать и устанавливать мобильное платежное приложение, такое как мобильное платежное приложение 210, показанное на фиг. 2. В качестве неограничивающего примера, мобильное платежное приложение может быть цифровым кошельком, приложением продавца, платежным приложением, ориентированным на поставщика и тому подобным. Пользователь мобильного устройства 600 может использовать блок 620 ввода, чтобы вводить команды и верифицировать идентичность пользователя как держателя карты, соответствующего платежным счетам, включенным в мобильное платежное приложение. Блок 620 ввода может включать в себя клавиатуру, сенсорную панель, мышь, модуль распознавания речи, модуль распознавания движения и тому подобное, для приема ввода печатанием, касанием, входом, голосом или съемкой от пользователя.
Процессор 610 может исполнять мобильное платежное приложение в пользовательском домене мобильного устройства 600 в ответ на прием ввода команды пользователем через блок 620 ввода. Как описано в настоящем документе, пользовательский домен может включать в себя операционную среду, в которой мобильные приложения исполняются и доступны пользователю мобильного устройства. Блок 630 импорта может импортировать множество ключей шифрования для использования мобильным платежным приложением в системный домен мобильного устройства 600. Например, блок 630 импорта может импортировать ключи в хранилище ключей, включенное в системный домен. Согласно различным аспектам, системный домен может иметь более ограниченную операционную среду, чем пользовательский домен, и может управляться операционной системой мобильного устройства 600. Например, системный домен может быть недоступен для пользователя мобильного устройства 600 и может находиться под исключительным контролем операционной системы. Пример операционной системы включает в себя Google Android, Apple iOS, Windows Phone OS и тому подобное.
Процессор 610 может зашифровывать платежную информацию мобильного платежного приложения в системном домене с использованием одного или более импортированных ключей во время исполнения мобильного платежного приложения в пользовательском домене. Например, процессор 610 может зашифровывать платежную информацию из одной или более платежных карт, ассоциированных с мобильным платежным приложением. В качестве примера, зашифрованная платежная информация может включать в себя основной номер счета (PAN), дату истечения срока действия, код безопасности карты, PIN, маркированную платежную информацию и тому подобное. В качестве другого примера, зашифрованная платежная информация может включать в себя учетные данные, такие как сообщения, переданные между мобильным устройством 600 и платежной сетью, CMS, сервером администрирования и тому подобное. Соответственно, путем импорта ключей в системный домен и шифрования платежной информации в системном домене, конфиденциальная информация о держателе карты и конфиденциальная информация о платежном приложении (т.е., ключи, операции шифрования, платежная информация и т.д.) могут быть предотвращены от представления в пользовательском домене и могут быть ограничены до системного домена. Также, системный домен может включать в себя дополнительные уровни защиты от пользовательского домена. Например, шлюз безопасности может быть реализован между доменом пользователя и системным доменом, тем самым дополнительно защищая системный домен от получения доступа взломщиком к пользовательскому домену.
Передатчик 640 может передавать зашифрованную платежную информацию продавцу (т.е., серверу продавца или другому вычислительному устройству) при попытке заплатить за транзакцию с продавцом за товары и/или услуги. Согласно различным примерным вариантам осуществления, передатчик 640 может передавать зашифрованную платежную информацию из системного домена непосредственно продавцу без переноса зашифрованной платежной информации через пользовательский домен. Соответственно, конфиденциальные зашифрованные данные могут быть предотвращены от представления в пределах пользовательского домена мобильного устройства 600 и могут быть ограничены до импорта и работы в пределах системного домена.
Множество ключей шифрования, импортированных блоком 630 импорта в системный домен (например, принятых системным доменом), может включать в себя различные ключи, такие как общедоступные ключи, секретные ключи, мобильные ключи, мобильные ключи сеансов, случайно сгенерированные ключи и тому подобное. Например, ключи шифрования могут включать в себя по меньшей мере один мобильный ключ для дешифрования содержимого, принятого от системы администрирования учетных данных (CMS), и шифрования содержимого, подлежащего отправке к CMS. В качестве другого примера, множество ключей шифрования может включать в себя пару ключей (ICC) карты с интегральной схемой для генерации сигнатуры CDA. В дополнение к импорту ключей в системный домен, процессор 610 может генерировать ключи шифрования в системном домене для использования с мобильным платежным приложением и хранить сгенерированный ключ шифрования в хранилище ключей системного домена. Например, процессор 610 может генерировать ключ шифрования локальной базы данных (LDE) для дешифрования и шифрования данных, хранящихся в локальной базе данных, используемой мобильным платежным приложением.
Фиг. 7 иллюстрирует способ 700 платежа, выполняемый в нескольких доменах мобильного устройства в соответствии с примерным вариантом осуществления. Со ссылкой на фиг. 7, в 710 пользовательский домен и системный домен установлены в пределах мобильного устройства. Пользовательский домен может включать в себя операционную среду, в которой мобильные приложения исполняются и доступны пользователю мобильного устройства. Системный домен может иметь более ограниченную операционную среду, чем пользовательский домен, и может управляться операционной системой мобильного устройства. Согласно различным примерным вариантам осуществления, системный домен может более интенсивно управляться операционной средой, чем пользовательский домен. Системный домен может иметь ограниченный доступ к нему и ограничения по типам операций, которые могут выполняться в нем. В качестве примера, системный домен может регулироваться или иным образом управляться операционной системой.
В 720, способ включает в себя исполнение мобильного платежного приложения в пользовательском домене мобильного устройства, и в 730 способ включает в себя импортирование множества ключей шифрования для использования мобильным платежным приложением в системный домен мобильного устройства. Хотя этап исполнения мобильного платежного приложения опережает импорт, следует учесть, что примерные варианты осуществления этим не ограничены. Например, ключи шифрования могут импортироваться перед исполнением мобильного платежного приложения. В качестве другого примера, ключи шифрования могут импортироваться в то же самое время, в которое исполняется мобильное платежное приложение. В 740, способ дополнительно включает в себя шифрование платежной информации мобильного платежного приложения в системном домене с использованием одного или более импортированных ключей во время исполнения мобильного платежного приложения в пользовательском домене. Согласно различным примерным вариантам осуществления, тип операций или функций, которые могут выполняться каждым ключом, может быть предотвращен или ограничен операционной системой мобильного устройства. Например, ключ может быть ограничен до использования только для шифрования и не для дешифрования (или наоборот). В качестве другого примера, ключ может импортироваться в системный домен, но не экспортироваться. В 750, способ дополнительно включает в себя передачу зашифрованной платежной информации продавцу, такому как сервер продавца или сервер третьей стороны, исполняющий веб-сайт продавца. Здесь, передача может включать в себя передачу зашифрованной платежной информации от системного домена непосредственно продавцу без переноса зашифрованной платежной информации через пользовательский домен.
В примере фиг. 7, импорт может включать в себя импорт множества ключей шифрования в хранилище ключей, действующее в системном домене. В этом случае, шлюз безопасности может существовать между пользовательским доменом и системным доменом, таким образом, добавляя другой уровень защиты к данным, хранящимся в системном домене. Также, системный домен может быть недоступным для пользователя мобильного устройства и может находиться под исключительным управлением операционной системы. В результате, ключи шифрования могут храниться и действовать в более безопасной среде во время процесса оплаты с использованием исполнения мобильного платежного приложения в пользовательском домене. Например, множество ключей шифрования может включать в себя по меньшей мере один мобильный ключ для дешифрования содержимого, принятого от системы администрирования платежных данных (CMS), пару ключей карты с интегральной схемой (ICC) для генерации сигнатуры CDA и тому подобное. Также, один или более ключей шифрования могут генерироваться в системном домене и храниться в системном домене, например, в хранилище ключей. В качестве примера, ключ шифрования локальной базы данных (LDE) может генерироваться для дешифрования и шифрования данных, хранящихся в локальной базе данных, используемой мобильным платежным приложением.
Согласно различным примерным вариантам осуществления, в настоящем документе описаны система и способ для засекречивания ключей шифрования мобильного платежного приложения. Примерные варианты осуществления импортируют, исполняют, высылают и передают и принимают ключи шифрования, используемые платежным приложением, через системный домен мобильного устройства. Системный домен может находиться под исключительным управлением мобильной операционной системы, тем самым ограничивая доступ к ключам шифрования и ограничивая операции, которые могут выполняться с использованием ключей шифрования.
Как использовано в настоящем документе, термины карта, карта транзакции, финансовая карта транзакции, платежная карта и тому подобное относятся к любой подходящей карте транзакции, такой как кредитная карта, дебетовая карта, предоплаченная карта, платежная карта, членская карта, рекламная карта, карта пассажира, часто летающего самолетами данной авиакомпании, идентификационная карта, подарочная карта и тому подобное. В качестве другого примера, термины могут относиться к любому другому устройству или носителям, которые могут содержать информацию платежного счета, таким как мобильные телефоны, смартфоны, персональные цифровые помощники (PDA), брелоки для ключей, компьютеры и тому подобное. Карта транзакции может использоваться в качестве способа платежа за выполнение транзакции.
Как будет понятно на основе предшествующего описания, вышеописанные примеры раскрытия могут быть реализованы с использованием методов компьютерного программирования или инжиниринга, включая компьютерное программное обеспечение, программно-аппаратные средства, аппаратные средства или любую их комбинацию или поднабор. Любая такая результирующая программа, имеющая считываемый компьютером код, может быть воплощена или обеспечена на одном или более энергонезависимых считываемых компьютером носителях, тем самым создавая компьютерный программный продукт, т.е. изделие промышленного производства, согласно обсужденным примерам раскрытия. Например, энергонезависимые считываемые компьютером носители могут представлять собой, без ограничения указанным, стационарный накопитель, дискету, оптический диск, магнитную ленту, флэш-память, полупроводниковую память, такую как постоянная память (ROM), и/или любую среду передачи/приема, такую как Интернет или другая сеть или линия связи. Изделие промышленного производства, содержащее компьютерный код, может быть произведено и/или использовано путем исполнения кода непосредственно с одного носителя, путем копирования кода с одного носителя на другой носитель или путем передачи кода по сети.
Компьютерные программы (также упоминаемые как программы, программное обеспечение, приложения программного обеспечения, ʺappʺ или код) могут включать в себя машинные инструкции для программируемого процессора и могут быть реализованы в высокоуровневом процедурном и/или объектно-ориентированном языке программирования и/или в ассемблерном/машинном языке. Как использовано в настоящем документе, термины ʺмашиночитаемый носительʺ и ʺсчитываемый компьютером носительʺ относятся к любому компьютерному программному продукту, аппаратуре и/или устройству (например, магнитным дискам, оптическим дискам, памяти, устройствам программируемой логики (PLD)), используемым для предоставления машинных инструкций и/или данных в программируемый процессор, включая машиночитаемый носитель, который принимает машинные инструкции в качестве машиночитаемого сигнала. ʺМашиночитаемый носительʺ и ʺсчитываемый компьютером носительʺ, однако, не включают в себя переходные (временные) сигналы. Термин ʺмашиночитаемый сигналʺ относится к любому сигналу, который может использоваться для предоставления машинных инструкций и/или любого другого вида данных в программируемый процессор.
Приведенные выше описания и иллюстрации процессов в настоящем документе не должны рассматриваться как подразумевающие фиксированный порядок для выполнения этапов процесса. Напротив, этапы процесса могут выполняться в любом порядке, который является осуществимым, включая одновременное выполнение по меньшей мере некоторых этапов.
Хотя настоящее изобретение было описано в связи с конкретными примерными вариантами осуществления, следует понимать, что различные изменения, подстановки и поправки, очевидные специалистам в данной области техники, могут быть выполнены в раскрытых вариантах осуществления без отклонения от сущности и объема изобретения, как изложено в прилагаемой формуле изобретения.
1. Способ функционирования мобильного устройства, содержащий этапы, на которых:
исполняют мобильное платежное приложение в пользовательском домене мобильного устройства, причем пользовательский домен содержит операционную среду, в которой мобильные приложения исполняются и доступ к ним осуществляется пользователем мобильного устройства;
импортируют множество ключей шифрования для использования с мобильным платежным приложением в системный домен мобильного устройства, причем системный домен содержит более безопасную операционную среду, управляемую операционной системой мобильного устройства;
шифруют платежную информацию мобильного платежного приложения в системном домене с использованием одного или более импортированных ключей во время исполнения мобильного платежного приложения в пользовательском домене; и
передают зашифрованную платежную информацию продавцу.
2. Способ по п.1, в котором упомянутое импортирование содержит импортирование множества ключей шифрования в хранилище ключей, работающее в системном домене.
3. Способ по п.1, в котором между пользовательским доменом и системным доменом имеется шлюз безопасности.
4. Способ по п.1, в котором упомянутое множество ключей шифрования, импортированных в системный домен, содержат по меньшей мере один мобильный ключ для дешифрования содержимого, принятого от системы администрирования учетных данных (CMS).
5. Способ по п.1, в котором упомянутое множество ключей шифрования, импортированных в системный домен, содержат пару ключей (ICC) карты с интегральной схемой для генерации сигнатуры CDA.
6. Способ по п.1, дополнительно содержащий этап, на котором генерируют ключ шифрования в системном домене для использования с мобильным платежным приложением и сохраняют сгенерированный ключ шифрования в системном домене.
7. Способ по п.6, в котором сгенерированный ключ шифрования содержит ключ шифрования локальной базы данных (LDE) для дешифрования и шифрования данных, хранящихся в локальной базе данных, используемой мобильным платежным приложением.
8. Способ по п.1, в котором системный домен недоступен для пользователя мобильного устройства и находится под исключительным управлением операционной системы.
9. Способ по п.1, в котором упомянутая передача содержит этап, на котором переносят зашифрованную платежную информацию из системного домена в пользовательский домен и передают зашифрованную платежную информацию из пользовательского домена продавцу.
10. Мобильное устройство, содержащее:
процессор, выполненный с возможностью исполнять мобильное платежное приложение в пользовательском домене мобильного устройства, причем пользовательский домен содержит операционную среду, в которой мобильные приложения исполняются и доступ к ним осуществляется пользователем мобильного устройства; и
блок импорта, выполненный с возможностью импортировать множество ключей шифрования для использования мобильным платежным приложением в системный домен мобильного устройства, причем системный домен содержит более безопасную операционную среду, управляемую операционной системой мобильного устройства;
при этом процессор дополнительно выполнен с возможностью шифровать платежную информацию мобильного платежного приложения в системном домене с использованием одного или более импортированных ключей во время исполнения мобильного платежного приложения в пользовательском домене.
11. Мобильное устройство по п.10, дополнительно содержащее передатчик, выполненный с возможностью передавать зашифрованную платежную информацию продавцу.
12. Мобильное устройство по п.11, в котором процессор переносит зашифрованную платежную информацию из системного домена в пользовательский домен, и передатчик передает зашифрованную платежную информацию из пользовательского домена продавцу.
13. Мобильное устройство по п.10, в котором блок импорта импортирует множество ключей шифрования в хранилище ключей, включенное в системный домен.
14. Мобильное устройство по п.10, в котором между пользовательским доменом и системным доменом имеется шлюз безопасности.
15. Мобильное устройство по п.10, при этом множество ключей шифрования, импортированных в системный домен, содержит по меньшей мере один мобильный ключ для дешифрования содержимого, принятого от системы администрирования платежных данных (CMS).
16. Мобильное устройство по п.10, при этом упомянутое множество ключей шифрования, импортированное в системный домен, содержат пару ключей (ICC) карты с интегральной схемой для генерации сигнатуры CDA.
17. Мобильное устройство по п.10, в котором процессор дополнительно выполнен с возможностью генерировать ключ шифрования в системном домене для использования с мобильным платежным приложением и сохранять сгенерированный ключ шифрования в системном домене.
18. Мобильное устройство по п.16, при этом сгенерированный ключ шифрования содержит ключ шифрования локальной базы данных (LDE) для дешифрования и шифрования данных, хранящихся в локальной базе данных, используемой мобильным платежным приложением.
19. Мобильное устройство по п.10, в котором системный домен недоступен для пользователя мобильного устройства и находится под исключительным управлением операционной системы мобильного устройства.
20. Долговременный машиночитаемый носитель, на котором сохранены инструкции, которые при их исполнении предписывают компьютеру выполнять способ функционирования мобильного устройства, содержащий этапы, на которых:
исполняют мобильное платежное приложение в пользовательском домене мобильного устройства, причем пользовательский домен содержит операционную среду, в которой мобильные приложения исполняются и доступ к ним осуществляется пользователем мобильного устройства;
импортируют множество ключей шифрования для использования мобильным платежным приложением в системный домен мобильного устройства, причем системный домен содержит более безопасную операционную среду, управляемую операционной системой мобильного устройства;
шифруют платежную информацию мобильного платежного приложения в системном домене с использованием одного или более импортированных ключей во время исполнения мобильного платежного приложения в пользовательском домене; и
передают зашифрованную платежную информацию продавцу.
