RU2724793C1

RU2724793C1 - Способ удаленной загрузки комплекта ключей в смарт-терминал

Info

Publication number: RU2724793C1
Application number: RU2019130886A
Authority: RU
Inventors: Игорь Владимирович Воронин; Денис Георгиевич Видякин
Original assignee: Общество с ограниченной ответственностью "ЭВОТОР"
Priority date: 2019-10-01
Filing date: 2019-10-01
Publication date: 2020-06-25

Abstract

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

Description

Область техники

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

Уровень техники

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

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

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

Этот ключ является фундаментом обеспечения безопасности и к его вводу в устройство предъявляются особые требования.

Обычная схема подразумевает генерацию 2 и более компонент KLK которые распечатываются на специальных конвертах (подобно пин-конвертам карт).

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

Причем требуется, чтобы каждая компонента вводилась отдельным офицером. Недопустимо чтобы один человек вводил более одной компоненты.

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

Примеры реализации оборудования, в частности смарт-терминала, раскрыты в полезной модели RU 190099, опубл. 18.06.2019.

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

Раскрытие изобретения

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

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

Заявленный технический результат достигается тем, что способ удаленной загрузки комплекта криптографических ключей в смарт-терминал, предназначенный для проведения финансовых операций по пластиковым картам и техническим средствам бесконтактной оплаты, включает этапы, на которых при производстве смарт-терминала в его конструкцию вводят рабочий модуль (СМ), выполненный с возможностью генерирования уникальной случайной пары ключей в момент производства, состоящей из публичного ключа (Pub_DEV) и секретного ключа (Priv_DEV), который никогда не передается и хранится в рабочем модуле (СМ), при этом на начальном этапе инициирования при производстве рабочий модуль (СМ) генерирует упомянутую случайную пару ключей (Pub_DEV, Priv_DEV), далее рабочий модуль (СМ) генерирует цифровой запрос (Certificate Sign Request - CSR) на получение сертификата с удаленного сервера безопасности через доверенный канал связи. Сервер безопасности принимает запрос от производителя терминала по доверенному защищенному каналу связи и генерирует уникальный сертификат рабочего модуля (СМ) - (Crt_DEV) для поступившего запроса с использованием аппаратного модуля безопасности (HSM) и секретного ключа сервера (KRD), данный сертификат сохраняется в базе данных поставщика услуг на удаленном сервере и отправляется на рабочий модуль (СМ), который осуществляет процедуру проверки полученного сертификата и его сохранения в энергонезависимой флэш-памяти при подтверждении, что сертификат является подлинным. После генерации сертификата рабочего модуля (СМ), сертификат (Crt_DEV) устанавливается в терминал и передается клиенту.

Клиенту необходимо получить и загрузить в рабочий модуль (СМ) свой уникальный симметричный секретный ключ (KLK). Для этого рабочий модуль (СМ) формирует запрос с указанием своего серийного номера и случайного числа (RND). Сервер безопасности поставщика услуг формирует секретный ключ (KLK) с использованием аппаратного модуля безопасности (HSM) и шифрует его временным ключом. Временный ключ шифруется публичным сертификатом (Crt_DEV), который извлекается из базы данных (БД). Шифрованный временный ключ совместно со случайным числом (RND) подписывается ключом распространения (KDH) (секретный ключ, используемый сервером). Все операции у поставщика выполняются с использованием (HSM).

Получив ответ с секретным ключом (KLK) от сервера безопасности поставщика рабочий модуль (СМ) проверяет подпись ответа на основании сертификата ключа (KDH), который встроен в рабочий модуль (СМ), расшифровывает ответ с помощью своего секретного ключа (Priv_DEV), Если все проверки прошли успешно - принятый секретный ключ (KLK) сохраняется внутри рабочего модуля (СМ).

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

Краткое описание чертежей

На Фиг. 1 схематично приведено взаимодействие смарт-терминала и сервера Эвотор.

На Фиг. 2а-2 г представлены этапы загрузки комплекта ключей в смарт-терминал.

Осуществление изобретения

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

Под Эвотор подразумевается сервер компании со специализированным программным обеспечением (ПО), подключенный к базе данных (БД) компании, на который поступают запросы на генерацию сертификатов от рабочих модулей (СМ), находящихся на финальном этапе производственного цикла. Под Эвотор 5i подразумевается смарт-терминал (касса).

Сервер на основе запроса от рабочего модуля (СМ) генерирует сертификат для модуля, а так же сохраняет сертификат во внутренней БД компании Эвотор для дальнейшего использования. Решение используется в финансовой области для проведения платежей по пластиковым картам.

Конечная цель проекта - обеспечить прием карт на кассе Эвотор 5i (смарт-терминал компании Эвотор).

Заявленный алгоритм следует рекомендациям протокола:

«Х9 TR34-2012 Interoperable Method for Distribution of Symmetric Keys using Asymmetric Techniques:, Registered with American National Standards Institute Date Registered: August 28, 2012.»

Недостатком схемы является повышенные требования к оборудованию, однако использованный в Эвотор 5i процессор Мах32560 обеспечивает необходимую производительность для работы с криптографией на публичных ключах.

При этом решение можно использовать с любым смарт-терминалом, так как во всех POS EFT терминалах используется криптографический процессор/контроллер на базе архитектуры ARM (https://ru.wikipedia.org/wiki/ARM (%D0%B0%D1%80%D1%85%D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%B0)

Например: https://www.arm.com/products/silicon-ip-cpu/cortex-m/cortex-m3.

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

Для того, чтобы можно было принимать карты и вводить пин-код в рабочий модуль (СМ) необходимо загрузить в него комплект криптографических ключей для обеспечения безопасности связи в соответствии с требованиями стандарта PCI DSS (https://www.pcisecuritystandards.org/pci_security/maintaining_payment_security).

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

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

На производстве каждый модуль (СМ) генерирует внутри себя уникальную случайную пару ключей RSA длиной 2048 бит. Через защищенный канал связи (СМ) отправляет запрос на генерацию сертификата на сервер (сервер Эвотор (Evotor) - сервер компании предоставления услуг). Сервер Эвотор принимает запрос на генерацию сертификата по доверенному каналу и генерирует сертификат для поступившего запроса внутри HSM (Hardware secure module) с использованием секретного ключа Priv_KRD Эвотор. Созданный сертификат отправляется в (СМ), который проверяет поступивший сертификат и сохраняет его внутри себя для дальнейшего использования. Для загрузки нового комплекта симметричных ключей (СМ) формирует запрос на KDH (Key distribution host) Эвотор с указанием своего серийного номера и случайного числа. KDH Эвотор формирует случайный KLK (Key load key) для СМ и шифрует его случайным временным ключем. KDH шифрует временный ключ сертификатом (СМ) (получаемым из локальной БД Эвотор), подписывает шифрованный временный ключ и полученное RND ключем KDH и отправляет ответ на (СМ), который проверяет подпись KDH на основе встроенного в ПО сертификата KDH, выполняет остальные проверки (к примеру - защита от повтора ответа). Если подпись верна - на Private части ключа (СМ) расшифровывает ответ и извлекает временный ключ. С использованием временного ключа расшифровывается KLK, созданный в KDH для этого (СМ). Далее (СМ) запрашивает у KDH Эвотор все остальные симметричные ключи, необходимые ему для работы. KDH Эвотор формирует комплект случайных ключей и отправляет их в (СМ), шифрованными на KLK. (СМ) принимает комплект ключей, расшифровывает их на сохраненном KLK и отправляет проверочные значения ключей на KDH. KDH сравнивает принятые от (СМ) проверочные значения комплекта ключей со своими и в случае совпадения отправляет подтверждение на (СМ). (СМ) переводит принятый комплект ключей в рабочий режим и использует эти ключи для проведения транзакций (шифрование ПИН, сообщений и тд.)

Таким образом, используя пару ключей и таймстамп, осуществляется генерирование запроса CSR, после чего получают сертификат уже от Эвотор Пэй.

Для более наглядной иллюстрации алгоритма заявленного способа на фиг. 2а-2г приведена последовательность операций по загрузке ключей.

Фиг 2а: Генерация уникального ключа на производстве

- (СМ) создает пару ключей модуля. Эти ключи уникальны для каждого модуля. Prvate часть никогда не покидает пределов СМ.

- (СМ) создает Certificate Sign Request (CSR) по доверенному каналу отправляет его на хост Эвотор.

- Сервер Эвотор выполняет подпись CSR ключом Priv_KRD с использованием криптографического модуля (HSM - hardware security module) и формирует сертификат устройства.

- Этот сертификат сохраняется в БД Эвотор, а так же отправляется на (СМ).

- (СМ) проверяет, что сертификат соответствует CSR и сохраняет его у себя в энергонезависимой флэш-памяти.

Фиг. 2б: Команды от Эвотор на (СМ)

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

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

Фиг. 2в: Первичная установка ключа шифрования ключей (KLK)

- На основе созданной на шаге1 пары ключей СМ формирует запрос на загрузку KLK в Эвотор.

- Эвотор проверяет валидность (достоверность) запроса от модуля, проверяет статус модуля по внутренней БД и если все хорошо, генерирует ключ KLK для (СМ)

- Далее Эвотор генерирует сессионный симметричный ключ и шифрует им KLK. Сессионный же ключ в свою очередь шифруется публичным сертификатом (СМ), получаемым из БД. Кроме того на ответ формируется подпись на private ключе KDH. В блок данных для подписи входит timestamp или RND принятое от СМ.

- (СМ) принимает ответ от Эвотор и на основании public ключа KDH проверяет подпись ответа. Публичный ключ KDH встроен в ПО СМ и не может быть изменен.

- Если подпись совпала - (СМ) расшифровывает сессионный ключ своим private ключом и далее с помощью сессионного ключа извлекает KLK и сохраняет KLK внутри себя.

Фиг. 2г: Получение и смена комплекта ключей

- После того, как в (СМ) установлен KLK происходит первичное получение или обновление комплекта симметричных ключей для работы (СМ). Для этого (СМ) отправляет запрос в Эвотор с проверочным значением ключа KLK 1.

- БД эвотор на основании проверочного значения понимает, какой комплект ключей следует выслать на (СМ). При необходимости генерируется новый комплект. В этот новый комплект входит ключ KLK 2. Все ключи комплекта шифруются под KLK 2. Сам KLK 2 шифруется под KLK 1.

- (СМ) принимает криптограммы ключей, расшифровывает их, формирует временный набор ключей, вычисляет проверочные значения для ключей из временного набора и отправляет их в Эвотор.

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

Claims

Способ удаленной загрузки комплекта криптографических ключей в смарт-терминал, предназначенный для проведения финансовых операций по пластиковым картам и техническим средствам бесконтактной оплаты, включает этапы, на которых при производстве смарт-терминала в его конструкцию вводят рабочий модуль (СМ), выполненный с возможностью генерирования уникальной случайной пары ключей в момент производства, состоящей из публичного ключа (Pub_DEV) и секретного ключа (Priv_DEV), который никогда не передается и хранится в рабочем модуле (СМ), при этом на начальном этапе инициирования при производстве рабочий модуль (СМ) генерирует упомянутую случайную пару ключей (Pub_DEV, Priv_DEV), далее рабочий модуль (СМ) генерирует цифровой запрос (CSR) на получение сертификата с удаленного сервера безопасности через доверенный канал связи, в свою очередь сервер безопасности принимает запрос от производителя терминала по доверенному защищенному каналу связи и генерирует уникальный сертификат рабочего модуля (СМ) - сертификат (Crt_DEV) для поступившего запроса с использованием аппаратного модуля безопасности (HSM) и секретного ключа сервера (KRD), данный сертификат сохраняется в базе данных поставщика услуг на удаленном сервере и отправляется на рабочий модуль (СМ), который осуществляет процедуру проверки полученного сертификата и его сохранения в энергонезависимой флэш-памяти при подтверждении, что сертификат является подлинным, после генерации сертификата рабочего модуля (СМ), сертификат (Crt_DEV) устанавливается в терминал, далее рабочий модуль (СМ) формирует запрос с указанием своего серийного номера и случайного числа (RND), сервер безопасности поставщика услуг формирует секретный ключ (KLK) с использованием аппаратного модуля безопасности (HSM) и шифрует его временным ключом, временный ключ шифруется сертификатом (Crt_DEV), который извлекается из базы данных (БД) сервера поставщика сертификатов, шифрованный временный ключ совместно с RND подписываются ключом распространения (KDH), при этом все операции у поставщика выполняются с использованием аппаратного модуля безопасности (HSM), получив ответ с секретным ключом (KLK) от сервера безопасности поставщика, рабочий модуль (СМ) проверяет подпись ответа на основании сертификата ключа (KDH), который встроен в рабочий модуль (СМ), расшифровывает ответ с помощью своего секретного ключа (Priv_DEV), и если все проверки прошли успешно, принятый секретный ключ (KLK) сохраняется внутри рабочего модуля (СМ), после получения секретного ключа (KLK) рабочим модулем (СМ) осуществляется запрос на сервер поставщика услуг о предоставлении комплекта симметричных ключей для использования в работе рабочего модуля (СМ), сервер поставщика услуг формирует комплект случайных ключей и отправляет их в рабочий модуль (СМ) шифрованными секретным ключом (KLK), рабочий модуль (СМ) принимает комплект случайных ключей, расшифровывает их секретным ключом (KLK) и отправляет проверочные значения ключей на сервер распространения ключей (KDH), который осуществляет процедуру сравнения проверочного значения ключей со своими и при совпадении отправляет подтверждение на рабочий модуль (СМ), который переводит принятый комплект ключей в рабочий режим и использует эти ключи для проведения транзакций.