УПРАВЛЕНИЕ КОНФИДЕНЦИАЛЬНОЙ СВЯЗЬЮ

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

[0001] Настоящая заявка не является предварительной и притязает на приоритет предварительной заявки на патент США № 62/116357, поданной 13 февраля 2015 года (номер дела патентного поверенного 079900-0925515), которая включена в данный документ с помощью ссылки во всей своей полноте для всех целей.

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

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

[0003] Варианты осуществления настоящего изобретения устраняют эти недостатки и другие недостатки по отдельности и вместе.

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

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

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

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

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

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

КРАТКОЕ ОПИСАНИЕ ГРАФИЧЕСКИХ МАТЕРИАЛОВ

[0009] На фиг. 1 показана связь между клиентским компьютером и серверным компьютером согласно некоторым вариантам осуществления настоящего изобретения.

[0010] На фиг. 2 показан приведенный в качестве примера процесс генерирования и отправки сообщения с запросом согласно некоторым вариантам осуществления.

[0011] На фиг. 3 показан приведенный в качестве примера процесс принятия и обработки сообщения с запросом согласно некоторым вариантам осуществления.

[0012] На фиг. 4 показан приведенный в качестве примера процесс генерирования и отправки сообщения с ответом согласно некоторым вариантам осуществления.

[0013] На фиг. 5 показан приведенный в качестве примера процесс принятия и обработки сообщения с ответом согласно некоторым вариантам осуществления.

[0014] На фиг. 6 показаны пример первого сообщения с запросом, отправленного клиентским компьютером на серверный компьютер, и обработка первого сообщения с запросом серверным компьютером согласно некоторым вариантам осуществления.

[0015] На фиг. 7 показаны пример последующего сообщения с запросом, отправленного клиентским компьютером на серверный компьютер, и обработка последующего сообщения с запросом серверным компьютером согласно некоторым вариантам осуществления.

[0016] На фиг. 8 показаны пример сообщения с ответом, отправленного серверным компьютером на клиентский компьютер, и генерирование сообщения с ответом согласно некоторым вариантам осуществления.

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

[0018] На фиг. 10 показан приведенный в качестве примера процесс шифрования сообщения согласно некоторым вариантам осуществления.

[0019] На фиг. 11 показан другой приведенный в качестве примера процесс шифрования сообщения согласно некоторым вариантам осуществления.

[0020] На фиг. 12 показан приведенный в качестве примера процесс расшифровки сообщения согласно некоторым вариантам осуществления.

[0021] На фиг. 13 показан другой приведенный в качестве примера процесс расшифровки сообщения согласно некоторым вариантам осуществления.

[0022] На фиг. 14 показан другой приведенный в качестве примера процесс расшифровки сообщения согласно некоторым вариантам осуществления.

[0023] На фиг. 15 показан приведенный в качестве примера процесс генерирования HTTP-сообщения с запросом согласно некоторым вариантам осуществления.

[0024] На фиг. 16 показан приведенный в качестве примера процесс обработки HTTP-сообщения с запросом согласно некоторым вариантам осуществления.

[0025] На фиг. 17 показан приведенный в качестве примера процесс генерирования HTTP-сообщения с ответом согласно некоторым вариантам осуществления.

[0026] На фиг. 18 показан приведенный в качестве примера процесс обработки HTTP-сообщения с ответом согласно некоторым вариантам осуществления.

[0027] На фиг. 19 показан приведенный в качестве примера процесс шифрования для шифрования закрытых данных согласно некоторым вариантам осуществления.

[0028] На фиг. 20 показан приведенный в качестве примера процесс расшифровки для расшифровывания данных согласно некоторым вариантам осуществления.

[0029] На фиг. 21 показано дерево решений для обработки сообщения с запросом для осуществления политик сервера согласно некоторым вариантам осуществления.

[0030] На фиг. 22 представлена высокоуровневая структурная схема компьютерной системы согласно некоторым вариантам осуществления.

ТЕРМИНЫ

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

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

[0033] Термин «пара открытого/закрытого ключей» может включать пару связанных криптографических ключей, сгенерированных субъектом. Открытый ключ может быть использован для открытых функций, таких как шифрование сообщения для отправки субъекту или для проверки цифровой подписи, которая предположительно была создана субъектом. Закрытый ключ, с другой стороны, может быть использован для закрытых функций, таких как расшифровка принятого сообщения или наложение цифровой подписи. Открытый ключ обычно авторизует орган, известный как Орган сертификации (CA), который хранит открытый ключ в базе данных и распределяет его любому другому субъекту, который запрашивает его. Закрытый ключ, как правило, хранится на безопасном носителе данных и обычно известен только субъекту. Однако, криптографические системы, описанные в данном документе, могут обладать механизмами восстановления ключа для восстановления потерянных ключей и избегания потери данных. Открытые и закрытые ключи могут иметь любой подходящий формат, включая формат, основанный на криптографическом алгоритме с открытым ключом (RSA) или криптографии на основе эллиптических кривых (ECC).

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

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

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

[0037] При обычном процессе орган сертификации принимает неподписанный сертификат от субъекта, подлинность которого известна. Неподписанный сертификат содержит открытый ключ, одно или несколько полей данных и хеш данных в сертификате. ОС подписывает сертификат закрытым ключом, соответствующим открытому ключу, включенному в сертификат ОС. Затем ОС может сохранить подписанный сертификат в базе данных и выдать подписанный сертификат субъекту.

[0038] «Криптографический объект nonce» может включать любое число, строку, последовательность битов или другое значение данных, предназначенное для использования совместно с одним сеансом связи. В некоторых случаях криптографический объект nonce может быть сгенерирован случайным или псевдослучайным образом. Как правило, криптографический объект nonce имеет достаточную длину, чтобы сделать незначительной вероятность независимого генерирования одинакового значения объекта nonce несколько раз.

[0039] «Заблокированный ключ», например, «заблокированный открытый ключ», может включать ключ, который был искажен или иным образом изменен в сравнении с его изначальным значением путем сочетания с другим элементом данных, таким как криптографический объект nonce (например, случайное или псевдослучайное число). Например, для генерирования «заблокированного открытого ключа» открытый ключ может быть умножен на объект nonce. Аналогично, для генерирования «заблокированного закрытого ключа» закрытый ключ может быть умножен на объект nonce.

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

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

[0042] «Идентификатор клиентского ключа» представляет собой идентификатор ключа, который идентифицирует один или более ключей, связанных с клиентским компьютером. «Идентификатор серверного ключа» представляет собой идентификатор ключа, который идентифицирует один или более ключей, связанных с серверным компьютером.

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

[0044] Защищенный идентификатор ключа может также содержать идентификатор ключа (с дополнительными данными или без них), который был зашифрован с помощью ключа шифрования (также именуемого как «ключ защиты идентификатора»). Например, защищенный идентификатор серверного ключа может содержать идентификатор серверного ключа, который отображается в клиентский закрытый ключ или клиентский открытый ключ. В некоторых вариантах осуществления защищенный идентификатор ключа может также содержать дополнительные данные, такие как заполняющие данные и/или случайное значение. В некоторых вариантах осуществления заполняющие данные могут представлять собой элемент постоянных данных. Наличие элемента постоянных данных в результате расшифровки защищенного идентификатора ключа может указывать на действительность или целостность идентификатора ключа. В некоторых других вариантах осуществления заполняющие данные могут содержать код аутентификации сообщений (КАС) идентификатора ключа или другой код, сгенерированный на основе идентификатора ключа. КАС может быть использован для аутентификации идентификатора ключа и/или других данных, включенных в защищенный идентификатор ключа. Заполняющие данные и/или случайное значение могут быть использованы для приведения длины защищенного идентификатора ключа или незашифрованных данных, содержащих идентификатор ключа, заполняющие данные и случайное значение, к фиксированной длине, чтобы исказить идентификатор ключа и сделать более трудным для перехватчика отличение защищенных идентификаторов ключей от любых других данных фиксированной длины. В некоторых вариантах осуществления идентификатор серверного ключа и/или дополнительные данные могут быть зашифрованы с помощью ключа шифрования идентификатора или какого-либо другого подходящего ключа шифрования для генерирования защищенного идентификатора ключа.

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

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

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

[0048] В некоторых вариантах осуществления информация, содержащаяся в сообщениях, может указывать на то, какие ключи шифрования идентификатора использовать и/или как формировать ключи шифрования идентификатора. Например, версия заголовка в сообщении A может быть использована для выбора первой базовой пары закрытого/открытого ключей для генерирования первого ключа шифрования идентификатора; тогда как другая версия заголовка в сообщении B может быть использована для выбора второй пары базовых закрытого/открытого ключей для генерирования второго отличного ключа шифрования идентификатора. В некоторых вариантах осуществления выбор базовой пары закрытого/открытого ключей или ключа шифрования идентификатора могут основываться на субъектности отправителя сообщения, удостоверяющей информации или любых других подходящих данных.

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

[0050] Одноразовый ключ может включать ключ, который сгенерирован заново для каждой новой транзакции или сеанса связи (также именуемый как «кратковременный ключ»). Альтернативно множество одноразовых ключей может быть сгенерировано из одного и того же основного или статического ключа, который остается неизменным в ходе множества транзакций или сеансов связи. Каждый из множества одноразовых ключей может быть изменен по-разному. Например, каждый из одноразовых ключей может быть по-разному заблокирован с помощью криптографического объекта nonce, фактора идентификации или других блокирующих факторов, или искажен иным образом.

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

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

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

[0054] «Совместно используемый секретный ключ» может включать любое значение данных или другую информацию, известную только уполномоченным сторонам в защищенной связи. Совместно используемый секретный ключ может быть сгенерирован любым подходящим способом, из любых подходящих данных. Например, алгоритм на основе метода Диффи-Хеллмана, такой как метод Диффи-Хеллмана на эллиптических кривых (ECDH), может быть использован для генерирования совместно используемого секретного ключа из закрытого ключа и открытого ключа. Совместно используемый секретный ключ запроса может относиться к совместно используемому секретному ключу, который используется для защиты безопасности сообщения с запросом. Совместно используемый секретный ключ ответа относится к совместно используемому секретному ключу, который используется для защиты безопасности сообщения с ответом.

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

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

[0057] «Данные протокола» относятся к любым данным в сообщении, которые указывают, как шифровать, расшифровывать или иным образом обрабатывать полезные данные сообщения, или к любому другому типу данных. Данные протокола могут содержать информацию о наборе шифров, информацию о дескрипторе данных (например, информацию об отображении данные-протокол) или другие подходящие данные. Набор шифров может относиться к определенной комбинации алгоритма обмена ключами (например, ECDHE_RSA), алгоритма шифрования, кода аутентификации сообщений, алгоритма аутентификации и/или других алгоритмов, используемых для защиты связи между клиентским компьютером и серверным компьютером. В некоторых вариантах осуществления данные протокола могут также содержать информацию о согласовании ключей, такую как алгоритмы согласования ключей и параметры, используемые для установления совместно используемых секретных ключей и/или для генерирования ключей. В некоторых вариантах осуществления данные протокола могут не содержать информации о наборе шифров. Вместо этого информация о наборе шифров может быть жестко закодирована, зафиксирована и/или косвенно согласована сторонами связи (например, клиентским компьютером и серверным компьютером).

[0058] Набор шифров может определять мощность канала (например, 128 бит, 192 бита или 256 бит), функцию формирования ключа (KDF) (например, AES-128, AES-394 или AES-256), алгоритм генерирования ключей или кривой согласования ключей криптографии на основе эллиптических кривых (ECC) (например, P-256, P-384 или P-521), рабочий режим блочного шифрования (например, параллелизуемый режим блочного шифрования (OCB), шифрование симметричного ключа, режим счетчика с CBC-MAC (CCM), EAX, шифрования, затем аутентификации (EtM) или режим счетчика с аутентификацией Галуа (GCM)), алгоритм создания цифровой подписи (например, алгоритм создания цифровой подписи на основе эллиптической кривой (ECDSA) или алгоритм создания цифровой подписи (DSA)), криптографическую хеш-функцию (например, SHA-256, SHA-384 или SHA-512), объект nonce (например, 16 байт, 24 байта или 32 байта) и тому подобное.

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

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

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

[0061] Варианты осуществления настоящего изобретения относятся к системам и способам управления конфиденциальной связью.

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

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

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

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

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

I. СИСТЕМЫ

[0067] На фиг. 1 показана связь между клиентским компьютером 101 и серверным компьютером 102 согласно некоторым вариантам осуществления. Оба из клиентского компьютера 101 и серверного компьютера 102 могут представлять собой любое подходящее вычислительное устройство (например, универсальные компьютеры, настольные или портативные компьютеры, планшеты, мобильные устройства, переносные устройства и т. д.).

[0068] Как показано на фиг. 1, клиентский компьютер 101 может отправлять сообщение с запросом на серверный компьютер 102. Сообщение с запросом может иметь любую подходящую форму. Например, в различных вариантах осуществления сообщение с запросом может представлять собой один или более пакетов TCP/IP, HTTP-сообщение с запросом или иметь любой другой подходящий формат. Как правило, сообщение с запросом может содержать защищенный идентификатор серверного ключа, который идентифицирует открытый ключ или сертификат, связанный с серверным компьютером. Сообщение с запросом может также содержать зашифрованные данные протокола и зашифрованные полезные данные. Зашифрованные данные протокола могут содержать защищенный идентификатор клиентского ключа для обеспечения клиентскому компьютеру возможности согласования асинхронных запросов и ответов.

[0069] Серверный компьютер 102 может обрабатывать сообщение с запросом. Серверный компьютер 102 может определять идентификатор серверного ключа из защищенного идентификатора серверного ключа в сообщении с запросом. Соответствующий серверный закрытый ключ может быть выбран на основе идентификатора серверного ключа и использован для генерирования одного или более ключей сеанса. Некоторые из ключей сеанса могут использоваться для расшифровки зашифрованных данных протокола в сообщении с запросом для получения данных протокола. Некоторые из других ключей сеанса могут использоваться для расшифровки зашифрованных полезных данных согласно данным протокола.

[0070] Серверный компьютер 102 может генерировать данные ответа для отправки на клиентский компьютер 101. Ответ может содержать защищенный идентификатор клиентского ключа. Ответ может также содержать новый защищенный идентификатор ключа для использования в последующем запросе. Дополнительно ответ может содержать зашифрованные данные протокола и зашифрованные полезные данные.

[0071] Клиентский компьютер 101 может определять идентификатор клиентского ключа из защищенного идентификатора клиентского ключа в сообщении с ответом и выбирать соответствующий клиентский закрытый ключ. Один или более ключей сеанса могут быть сгенерированы с помощью клиентского закрытого ключа. Некоторые из ключей сеанса могут использоваться для расшифровки зашифрованных данных протокола в сообщении с ответом для получения данных протокола. Некоторые из других ключей сеанса могут использоваться для расшифровки зашифрованных полезных данных согласно данным протокола.

II. Идентификация конфиденциальных ключей

[0072] На фиг. 2–9 показаны способы защиты идентификации ключей при осуществлении связи между клиентом и сервером. В частности, варианты осуществления согласно описанным способам могут обеспечивать включение в информационные сообщения, безопасным образом, идентификаторов ключей для использования клиентом или сервером. Спецификация ключей в информационных сообщениях может увеличивать количество информации, включенной в каждое сообщение, уменьшая тем самым общее количество сообщений, которые необходимы для аутентификации транзакций. Например, в вариантах осуществления обеспечена возможность установления аутентификации между клиентским компьютером и серверным компьютером в одной паре сообщения с запросом и сообщения с ответом. Кроме того, безопасность связи улучшена посредством включения неотслеживаемых ссылок на ключи, используемых каждой стороной (например, защищенных идентификаторов ключей), в информационные сообщения, так что только назначенная сторона может определить ключи, связанные с защищенными идентификаторами ключей. Идентификаторы ключей защищены в сообщениях таким образом, что ключи, связанные с идентификаторами ключей, остаются конфиденциальными, даже если сообщения перехвачены. Таким образом, варианты осуществления улучшают безопасность связи, не жертвуя эффективностью.

A. Способ генерирования сообщения с запросом

[0073] На фиг. 2 показан приведенный в качестве примера процесс 200 генерирования и отправки сообщения с запросом согласно некоторым вариантам осуществления. Как правило, процесс 200 может быть выполнен клиентским компьютером, таким как клиентский компьютер 101, для отправки сообщения на серверный компьютер (например, серверный компьютер 102). Некоторые или все аспекты процесса 200 (или любых других процессов, описанных в данном документе, или их вариантов и/или сочетаний) могут быть выполнены под управлением одного или более компьютеров/систем управления, снабженных исполняемыми командами, и могут быть реализованы в виде кода (например, исполняемых команд, одной или более компьютерных программ или одного или более приложений), исполняемого вместе на одном или более процессорах, аппаратным обеспечением или их сочетанием. Код может храниться в машиночитаемом носителе данных, например, в форме компьютерной программы, содержащей множество команд, выполняемых одним или несколькими процессорами. Машиночитаемый запоминающий носитель может быть постоянным. Порядок, в котором описаны операции, не предназначен для рассмотрения в качестве ограничения, и для осуществления процессов любое количество описанных операций можно сочетать в любом порядке и/или параллельно.

[0074] В блоке 202 определяется пара одноразовых клиентских ключей. Одноразовый клиентский ключ может содержать кратковременный закрытый ключ и кратковременный открытый ключ, которые генерирует клиентский компьютер для каждого нового запроса. Альтернативно одноразовый клиентский ключ может содержать статический закрытый и/или статический открытый ключ, которые блокируются, искажаются или иным образом изменяются по-разному для генерирования разных заблокированных ключей для каждого нового запроса. Например, точечное умножение может осуществляться по отношению к статическому клиентскому открытому ключу с некоторым другим элементом данных (например, случайным числом, криптографическим объектом nonce, фактором идентификации, данными транзакции и т. д.) для изменения значения клиентского открытого ключа для каждого запроса.

[0075] В некоторых вариантах осуществления клиентский компьютер может быть выполнен с возможностью осуществления связи с одним или более серверными компьютерами. По существу, клиентский компьютер может содержать набор из одной или более пар одноразовых клиентских ключей для некоторых или всех из одного или более серверных компьютеров. Каждая пара клиентских ключей в наборе из одной или более пар клиентских ключей соответствует конкретному запросу, отправленному на заданный серверный компьютер. Пара одноразовых клиентских ключей может быть определена для связывания с конкретным сообщением с запросом для конкретного серверного компьютера. В некоторых вариантах осуществления, например для асинхронной связи, клиентский компьютер может сохранять для заданного серверного компьютера определенное количество ранее сгенерированных пар клиентских ключей для ранее отправленных сообщений с запросом, так чтобы обеспечивать возможность расшифровки внеочередного сообщения с ответом, соответствующего ранее отправленному сообщению с запросом. Размер набора ранее сгенерированных пар клиентских ключей может быть ограничен предопределенным максимальным количеством (например, 10).

[0076] В блоке 204 определяется наличие защищенного идентификатора серверного ключа. В варианте осуществления клиентский компьютер может сохранять защищенные идентификаторы серверных ключей, принятые из предыдущих сообщений с ответами от одного или более серверных компьютеров. Каждый из одного или более серверных компьютеров может быть связан с набором из одного или более защищенных идентификаторов серверных ключей, некоторые или все из которых могут быть приняты из предыдущих сообщений с ответом от связанного серверного компьютера. Каждый из защищенных идентификаторов серверных ключей может быть связан с конкретным серверным открытым ключом и/или закрытым ключом. Отображения между серверными компьютерами и защищенными идентификаторами серверных ключей и между защищенными идентификаторами серверных ключей и соответствующими серверными открытыми ключами и/или сертификатами могут сохраняться в таблице, базе данных или любом другом подходящем хранилище данных, связанном с клиентским компьютером. Такие отображения могут использоваться для определения того, существует ли какой-либо защищенный серверный идентификатор (и следовательно серверный открытый ключ или сертификат) для заданного серверного компьютера, на который необходимо отправить сообщение с запросом. Наличие таких защищенных серверных идентификаторов указывает на то, что клиентский компьютер ранее принимал сообщения с ответом с серверного компьютера и извлекал из тех сообщений с ответом защищенные серверные идентификаторы. Отсутствие таких защищенных серверных идентификаторов может указывать на то, что клиентский компьютер никогда ранее не принимал сообщения с ответом от серверного компьютера или не принимал сообщения с ответом с серверного компьютера в течение предопределенного периода времени.

[0077] При определении в блоке 204 наличия одного или более защищенных идентификаторов серверных ключей для серверного компьютера, в блоке 206 защищенный идентификатор серверного ключа извлекается из одного или более защищенных идентификаторов серверных ключей. Как правило, выбирается защищенный идентификатор серверного ключа, связанный с самым недавно отправленным сообщением с ответом от серверного компьютера. В некоторых случаях самое недавно отправленное серверным компьютером сообщение с ответом не обязательно является самым недавно принятым клиентским компьютером сообщением с ответом, когда сообщения с ответом принимаются в нарушение последовательности.

[0078] В блоке 208 может извлекаться серверный открытый ключ или сертификат, связанный с извлеченным защищенным идентификатором серверного ключа. В некоторых вариантах осуществления защищенный идентификатор серверного ключа и соответствующий серверный открытый ключ или сертификат принимаются в одном и том же сообщении с ответом. В некоторых других вариантах осуществления защищенный идентификатор серверного ключа и соответствующий серверный открытый ключ или сертификат принимаются в разных сообщениях с ответом. В некоторых случаях защищенный идентификатор серверного ключа и/или связанный серверный открытый ключ или сертификат могут быть приняты в том же или другом канале связи (например, электронная почта, текст), отличном от канала связи для сообщений с запросом/ответом.

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

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

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

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

[0083] В блоке 214 совместно используемый секретный ключ запроса генерируется с помощью одноразового клиентского закрытого ключа, который определяется в блоке 202, и серверного открытого ключа или сертификата, определяемого на этапе 208 или 212. Совместно используемый секретный ключ запроса может использоваться для защиты (например, шифрования и/или расшифровки) сообщения с запросом, как обсуждается ниже. В некоторых вариантах осуществления серверный открытый ключ может определяться из цифрового сертификата серверного компьютера, который мог быть предварительно получен клиентским устройством (например, из сообщения с ответом от серверного компьютера или из какого-либо другого канала).

[0084] Совместно используемый секретный ключ запроса может генерироваться с помощью любого подходящего способа. Например, в вариантах осуществления, в которых используется криптография на основе эллиптических кривых, совместно используемый секретный ключ может быть определен с помощью протокола Диффи-Хеллмана на эллиптических кривых (ECDH).

[0085] Дополнительно или альтернативно совместно используемый секретный ключ запроса может генерироваться с помощью дополнительных данных. Такие дополнительные данные могут содержать фактор идентификации, который вычисляется с помощью идентификационных данных и аутентификационных данных. Идентификационные данные могут содержать любые данные или информацию, связанные с пользователем или клиентским устройством. Примеры идентификационных данных могут включать имя пользователя, связанное с клиентским устройством, организацию, связанную с клиентским устройством, платежную информацию, такую как номер основного счета (PAN) или маркер, связанный с клиентским устройством, дату завершения срока действия, связанную с PAN или маркером, сертификат, связанный с клиентским устройством, IMEI или серийный номер клиентского устройства, и т. д. Аутентификационные данные могут содержать любые данные или информацию, подходящие для аутентификации пользователя или клиентского устройства. Примеры аутентификационных данных могут включать пароль или фразу доступа, секретный ключ (например, закрытый ключ) и т. п. Фактор идентификации может содержать любые данные или информацию, определенные из идентификационных данных и/или аутентификационных данных. Например, в некоторых вариантах осуществления фактор идентификации может быть сгенерирован путем хеширования сочетания идентификационных данных и аутентификационных данных.

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

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

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

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

[0090] Ключ сеанса запроса может иметь любой подходящий формат (например, AES, DES, Blowfish и т. д.), любую подходящую длину и быть сгенерирован с помощью любой подходящей функции формирования ключа (KDF). Например, в одном варианте осуществления ключ сеанса запроса может быть сгенерирован с помощью алгоритма функции формирования ключа на основе пароля 2 (PBKDF2). В некоторых вариантах осуществления в качестве дополнительных входных данных для функции формирования ключа могут быть использованы другие данные клиентского компьютера, такие как идентификатор клиентского устройства.

[0091] В блоке 220 сообщение с запросом отправляется на серверный компьютер. Сообщение с запросом содержит зашифрованные данные запроса и защищенный идентификатор серверного ключа. Защищенный идентификатор серверного ключа может быть настоящим защищенным идентификатором серверного ключа, извлеченным в блоке 206, или случайным идентификатором ключа, определенным в блоке 210. Сообщение с запросом может также содержать одноразовый клиентский открытый ключ, который может быть или не быть заблокирован. Сообщение с запросом может также содержать информацию, которая указывает, как расшифровывать защищенный идентификатор серверного ключа. Например, сообщение с запросом может содержать номер версии протокола, который может использоваться принимающим серверным компьютером для выбора базового серверного ключа (ключей) для расшифровки защищенного серверного идентификатора.

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

B. Способы обработки сообщения с запросом

[0093] На фиг. 3 показан приведенный для примера процесс 300 принятия и обработки сообщения с запросом согласно некоторым вариантам осуществления. Как правило, процесс 300 может осуществляться серверным компьютером (например, серверным компьютером 102) в ответ на принятие сообщения с запросом с клиентского компьютера (например, клиентского компьютера 101). Однако в различных вариантах осуществления что-либо или все из способа 300 может выполняться другим субъектом.

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

[0095] В блоке 304 защищенный идентификатор серверного ключа расшифровывается с помощью ключа шифрования идентификатора для определения идентификатора серверного ключа. Ключ шифрования идентификатора может включать любой ключ шифрования, применяемый для шифрования и расшифровки идентификатора ключа. В некоторых вариантах осуществления ключ шифрования идентификатора может быть определен с помощью пары базовых открытого/закрытого ключей и/или других подходящих данных. Например, в некоторых вариантах осуществления ключ шифрования идентификатора может являться результатом точечного умножения базового открытого ключа и базового закрытого ключа. В данном случае серверный компьютер не должен независимо управлять ключами шифрования идентификатора, поскольку ключи шифрования идентификатора могут всегда быть восстановлены из существующей пары ключей. В качестве другого примера, ключ шифрования идентификатора представляет собой ключ шифрования, хранимый серверным компьютером (например, в безопасном хранилище).

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

[0097] В блоке 306 определяется, является ли идентификатор серверного ключа действительным. Действительный идентификатор серверного ключа соответствует действительному серверному открытому ключу или сертификату, действительному серверному закрытому ключу или и тому, и другому. Идентификатор серверного ключа может использоваться для поиска существующего серверного открытого ключа или сертификата, или серверного закрытого ключа в таблице или базе данных, поддерживаемой серверным компьютером. Если при поиске совпадение найдено, то идентификатор серверного ключа может считаться действительным. В ином случае идентификатор серверного ключа может быть определен недействительным. В некоторых вариантах осуществления при расшифровке защищенного идентификатора серверного ключа получают дополнительные данные, кроме идентификатора серверного ключа, такие как заполняющие данные и/или случайное число. Заполняющие данные могут использоваться для проверки подлинности и/или целостности идентификатора ключа. Например, заполняющие данные могут содержать код аутентификации сообщений идентификатора ключа и/или дополнительные данные. Альтернативно заполняющие данные могут представлять собой элемент постоянных или известных данных. Наличие элемента заполняющих данных в результате расшифровки защищенного идентификатора ключа могут указывать на действительность или целостность идентификатора ключа (например, что идентификатор ключа поступает из достоверного источника и/или что идентификатор ключа не был изменен). В некоторых других вариантах осуществления заполняющие данные могут содержать код аутентификации сообщений (КАС) идентификатора ключа или другой код, сгенерированный на основе идентификатора ключа.

[0098] Если в блоке 306 определено, что идентификатор серверного ключа действителен, то серверный закрытый ключ, связанный с идентификатором серверного ключа, извлекают в блоке 308. В некоторых вариантах осуществления идентификатор серверного ключа используется для извлечения открытого ключа или сертификата. Затем извлекается закрытый ключ, соответствующий открытому ключу или сертификату. Например, если идентификатор серверного ключа представляет собой серийный номер, извлекается цифровой сертификат с серийным номером. В другом примере, если идентификатор ключа представляет собой открытый ключ, определяется цифровой сертификат с открытым ключом. В некоторых других вариантах осуществления идентификатор серверного ключа используется непосредственно для извлечения соответствующего закрытого ключа. Отображения между идентификатором ключа и соответствующими открытыми ключами, сертификатами и/или закрытыми ключами могут сохраняться в таблице или базе данных, поддерживаемых серверным компьютером. В некоторых вариантах осуществления закрытый ключ может извлекаться из элемента безопасности или аппаратного модуля безопасности (HSM) на серверном компьютере.

[0099] Если в блоке 306 определено, что идентификатор серверного ключа не действителен, то базовый серверный закрытый ключ извлекается в блоке 310. Например, идентификатор серверного ключа, полученный после расшифровки защищенного идентификатора серверного ключа, может не соответствовать никакому существующему серверному открытому ключу, сертификату или закрытому ключу. Альтернативно или дополнительно установление подлинности идентификатора серверного ключа может потерпеть неудачу из-за отсутствия ожидаемых постоянных заполняющих данных или из-за несоответствия КАС идентификатора ключа. В таких случаях может извлекаться базовый закрытый ключ.

[0100] В блоке 312 зашифрованные данные запроса расшифровываются с помощью серверного закрытого ключа, извлеченного в блоке 308 или 310. В некоторых вариантах осуществления совместно используемый секретный ключ запроса определяется с помощью серверного закрытого ключа и одноразового клиентского открытого ключа. Одноразовый клиентский открытый ключ мог быть предоставлен в сообщении с запросом. Одноразовый клиентский открытый ключ может быть или не быть заблокирован или иным образом искажен. В некоторых вариантах осуществления ключ сеанса запроса определяется на основе совместно используемого секретного ключа запроса. Ключ сеанса запроса может использоваться для расшифровки зашифрованных данных запроса сообщения с запросом. Определение совместно используемого секретного ключа запроса и ключа сеанса запроса может быть подобным определению, которое описано в блоке 214, представленном на фиг. 2.

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

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

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

[0104] Могут быть извлечены аутентификационные данные, связанные с идентификатором клиентского компьютера, и/или идентификационные данные. Аутентификационные данные могут содержать любые данные или информацию, подходящие для аутентификации пользователя или клиентского компьютера. Примеры аутентификационных данных могут включать пароль или фразу доступа, секретный ключ (например, закрытый ключ) и т. п. В некоторых вариантах осуществления аутентификационные данные могут быть извлечены из базы данных устройств.

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

[0106] Одноразовый клиентский открытый ключ может быть проверен для подтверждения того, что одноразовый клиентский открытый ключ соответствует ожидаемому значению. Например, в некоторых случаях заблокированный одноразовый открытый ключ может быть сгенерирован с помощью одноразового открытого ключа, извлеченного из расшифрованных данных запроса, и фактора идентификации, определенного выше. Заблокированный одноразовый открытый ключ может затем сравниваться с одноразовым открытым ключом, принятым как часть сообщения с запросом (например, в незашифрованной текстовой части сообщения с запросом) для подтверждения соответствия ключей. Если ключи соответствуют, клиентский компьютер может быть аутентифицирован. Иначе, аутентификация может потерпеть неудачу.

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

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

C. Способы генерирования сообщения с ответом

[0109] На фиг. 4 показан приведенный в качестве примера процесс 400 генерирования и отправки сообщения с ответом согласно некоторым вариантам осуществления. Как правило, процесс 400 может быть осуществлен серверным компьютером (например, серверным компьютером 102) после принятия и обработки (например, согласно процессу 300) сообщения с запросом с клиентского компьютера (например, клиентского компьютера 101). Однако в различных вариантах осуществления что-либо или все из процесса 400 может выполняться другим субъектом.

[0110] В блоке 402 определяется идентификатор второго серверного закрытого ключа. Второй идентификатор серверного закрытого ключа идентифицирует второй серверный закрытый ключ и второй серверный открытый ключ или сертификат, которые отличаются от тех, которые связаны с защищенным идентификатором серверного ключа в принятом сообщении с запросом. Вторые открытый/закрытый ключи могут представлять собой статические ключи или одноразовые ключи. Второй открытый ключ или сертификат подлежит использованию клиентским компьютером в последующем осуществлении связи (например, в будущем сообщении с запросом). Благодаря изменению серверного ключа улучшается безопасность информационной связи, и потенциальный риск раскрытия одного серверного ключа сводится к минимуму. С применением способов, описанных в данном документе, может осуществляться такое чередование ключей конфиденциальным образом, которое является прозрачным для перехватчика.

[0111] В блоке 404 второй защищенный идентификатор серверного ключа генерируется для идентификатора второго серверного ключа. В некоторых вариантах осуществления второй защищенный идентификатор ключа может также содержать дополнительные данные, такие как заполняющие данные и/или случайное значение. Заполняющие данные могут содержать постоянные данные, известные серверному компьютеру, или код аутентификации сообщений (КАС) идентификатора ключа. Заполняющие данные и/или случайное значение могут быть использованы для приведения длины второго защищенного идентификатора ключа или незашифрованных данных, содержащих идентификатор ключа, заполняющие данные и случайное значение, до фиксированной длины, чтобы дополнительно исказить второй идентификатор ключа и сделать более трудным для перехватчика понимание отличения вторых защищенных идентификаторов ключей от любых других данных фиксированной длины. В некоторых вариантах осуществления случайное или псевдослучайное число может отличаться от случайного или псевдослучайного числа для предыдущего защищенного идентификатора серверного ключа, чтобы дополнительно искажать идентификатор ключа. Второй идентификатор серверного ключа и/или дополнительные данные могут быть зашифрованы с помощью ключа шифрования идентификатора или какого-либо другого подходящего ключа шифрования, известного серверному компьютеру.

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

[0113] В блоке 406 данные ответа зашифровываются с помощью второго серверного закрытого ключа. В некоторых вариантах осуществления совместно используемый секретный ключ ответа может быть сгенерирован с помощью второго серверного закрытого ключа и одноразового клиентского открытого ключа. Одноразовый клиентский открытый ключ может быть получен из сообщения с запросом и может быть или не быть заблокирован. В некоторых вариантах осуществления второй серверный открытый ключ и/или второй серверный закрытый ключ может быть заблокирован с помощью криптографического объекта nonce (например, случайного или псевдослучайного значения данных) и/или фактора идентификации. Совместно используемый секретный ключ ответа может быть сгенерирован с помощью заблокированного статического серверного закрытого ключа и одноразового клиентского открытого ключа. В альтернативном варианте осуществления статический серверный закрытый ключ не заблокирован. Вместо этого заблокирован одноразовый клиентский открытый ключ. Совместно используемый секретный ключ ответа может генерироваться с помощью любого подходящего способа, такого как ECDH.

[0114] Ключ сеанса ответа может быть определен с помощью совместно используемого секретного ключа ответа, KDF и других подходящих вспомогательных данных, таких как данные формирования ключей, при их наличии. Ключ сеанса ответа может также упоминаться как ключ защиты сообщения, поскольку он используется для защиты сообщения между клиентским компьютером и серверным компьютером. Примеры таких вспомогательных данных могут включать идентификатор серверного компьютера, идентификатор клиентского устройства и/или усеченный клиентский открытый ключ.

[0115] Могут быть определены данные ответа для включения в сообщение с ответом. Данные ответа могут содержать второй защищенный идентификатор серверного ключа. Дополнительно данные ответа могут необязательно содержать второй серверный открытый ключ или сертификат и/или данные протокола (например, информацию о наборе шифров, информацию об отображении данных), описанные в другом месте. В некоторых вариантах осуществления данные ответа могут содержать удостоверяющие данные, которые относятся к любым данным, специально предоставленным для данного клиентского устройства (например, мобильного устройства) или данной группы устройств, для обеспечения клиентскому устройству возможности проведения транзакций (например, платежных транзакций). Примеры удостоверяющих данных могут включать маркеры, PAN или другую информацию о счете, один или более ключей (например, LUK, используемые для генерирования криптограмм, ключ шифрования, заблокированные или незаблокированные статические открытые ключи и т. д.), параметры формирования ключей (например, для формирования SUK, который используется для генерирования криптограммы, совместно используемого секретного ключа, ключа шифрования и т. д.), параметры формирования криптограмм, информацию о цепочке сертификатов, параметры транзакций и любые другие подходящие данные. Данные ответа могут быть зашифрованы с помощью второго серверного закрытого ключа и включены в сообщение с ответом.

[0116] Кроме зашифрованных данных ответа, сообщение с ответом может также содержать информацию, которая не зашифрована с помощью второго серверного закрытого ключа. Такая информация может необязательно содержать защищенный идентификатор клиентского ключа, полученный из сообщения с запросом, цепочку сертификатов серверного компьютера, заблокированный или кратковременный второй серверный открытый ключ, криптографический объект nonce и тому подобное. Цепочка сертификатов серверного компьютера может быть проверена на подлинность клиентским компьютером для проверки субъектности серверного компьютера. Заблокированный или кратковременный второй серверный открытый ключ может быть проверен на подлинность клиентским компьютером в отношении второго серверного открытого ключа, включенного в зашифрованные данные запроса.

[0117] В блоке 408 сообщение с ответом, обсуждаемое выше, отправляется на клиентский компьютер. Сообщение с ответом содержит зашифрованные данные ответа и необязательно защищенный идентификатор клиентского ключа, полученный из сообщения с запросом. Однако в некоторых вариантах осуществления защищенный идентификатор ключа может быть исключен из сообщения с ответом. Сообщение с ответом может проходить через одного или более посредников (например, ненадежную сеть), прежде чем дойти до клиентского компьютера.

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

D. Способы обработки сообщения с ответом

[0119] На фиг. 5 показан приведенный в качестве примера процесс 500 принятия и обработки сообщения с ответом согласно некоторым вариантам осуществления. Как правило, процесс 500 может осуществляться клиентским компьютером (например, клиентским компьютером 101) в ответ на принятие сообщения с ответом (например, которое сгенерировано в ходе процесса 400) с серверного компьютера (например, серверного компьютера 102). Однако в различных вариантах осуществления что-либо или все из процесса 500 может выполняться другим субъектом.

[0120] В блоке 502 принимается сообщение с ответом, содержащее зашифрованные данные ответа и защищенный идентификатор клиентского ключа. В некоторых вариантах осуществления защищенный идентификатор клиентского ключа может быть использован для определения последовательности сообщений для обработки. Например, если сообщение (сообщения) с ответом, соответствующее ранее поданным запросам, еще не обработано, то этапы 502 и 504 могут быть отложены до тех пор, пока ранее отправленные сообщения с ответом не будут приняты и обработаны. Однако в некоторых вариантах осуществления защищенный идентификатор клиентского ключа может быть исключен.

[0121] Сообщение с ответом может содержать одноразовый серверный открытый ключ. Одноразовый серверный открытый ключ может соответствовать серверному закрытому ключу, который используется для генерирования сообщения с ответом. Одноразовый серверный открытый ключ может иметь заблокированный или иным образом искаженный вид статического серверного открытого ключа. Преимущество предоставления заблокированного статического серверного открытого ключа заключается в том, что статический открытый ключ серверного компьютера искажен, и сущность серверного компьютера защищена от перехвата. Когда статический серверный открытый ключ не заблокирован, криптографический объект nonce может быть предоставлен как часть данных ответа и использован для вычисления криптограмм. Например, криптографический объект nonce из сервера (энтропия) может быть использован или сохранен для дальнейшего формирования, или второй криптографический объект nonce может быть предоставлен как часть параметров формирования.

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

[0123] В блоке 506 зашифрованные данные ответа расшифровываются с помощью клиентского закрытого ключа для получения данных ответа. В некоторых вариантах осуществления совместно используемый секретный ключ ответа может быть определен с помощью клиентского закрытого ключа (который может быть кратковременным, статическим или полустатическим) и заблокированного серверного открытого ключа. В некоторых вариантах осуществления заблокированный серверный открытый ключ может быть принят с серверного компьютера, например, как часть сообщения с ответом, или из отдельного канала. В некоторых других вариантах осуществления в клиентский компьютер может быть предварительно загружен серверный открытый ключ или сертификат (который может быть статическим), или он иным образом имеет к ним доступ. Блокирующие данные (например, криптографический объект nonce, случайное число) могут быть предоставлены на клиентское устройство как часть сообщения с ответом или в отдельном канале. В таких случаях заблокированный серверный открытый ключ может быть сформирован клиентским компьютером с помощью серверного открытого ключа и предоставленных блокирующих данных. В некоторых вариантах осуществления криптографический объект nonce также может быть использован для проверки сертификата серверного компьютера, как обсуждается в другом месте. В некоторых вариантах осуществления совместно используемый секретный ключ ответа может быть сгенерирован из клиентского закрытого ключа и заблокированного серверного открытого ключа с помощью любого подходящего способа, такого как ECDH.

[0124] Ключ сеанса ответа может быть определен с помощью совместно используемого секретного ключа ответа, KDF и других подходящих вспомогательных данных, таких как данные формирования ключей, при их наличии. Ключ сеанса ответа может также упоминаться как ключ защиты сообщения, поскольку он используется для защиты сообщения между пользовательским устройством и серверным компьютером. Примеры таких вспомогательных данных могут включать идентификатор серверного компьютера, идентификатор клиентского компьютера и/или усеченный клиентский открытый ключ.

[0125] Ключ сеанса ответа может иметь любой подходящий формат (например, AES, DES, Blowfish и т. д.), любую подходящую длину и быть сгенерирован с помощью любой подходящей функции формирования ключа (KDF). Например, в одном варианте осуществления ключ сеанса ответа может быть сгенерирован с помощью алгоритма функции формирования ключа на основе пароля 2 (PBKDF2). В некоторых вариантах осуществления в качестве дополнительных входных данных для функции формирования ключа могут быть использованы другие данные, характерные для устройства пользователя, такие как идентификатор устройства пользователя или другая дактилоскопическая информация устройства.

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

[0127] Аутентификация серверного компьютера может осуществляться клиентским компьютером с помощью данных, включенных в сообщение с ответом. Может проверяться подлинность цепочки сертификатов серверного компьютера. Цепочка сертификатов компьютера сервера может быть проверена на подлинность с помощью любого подходящего онлайн или офлайн способа. Например, для каждого из одного или нескольких сертификатов в цепочке цифровая подпись сертификата может быть проверена на подлинность с помощью известного доверенного открытого ключа (например, открытого ключа органа сертификации, или открытого ключа субъекта, соответствующим образом авторизованного ОС). Например, в некоторых вариантах осуществления для проверки подлинности сертификата может быть использован алгоритм цифровой подписи, такой как алгоритм цифровой подписи на эллиптических кривых (ECDSA). В некоторых вариантах осуществления сертификат компьютера сервера может быть проверен с помощью криптографического объекта nonce, который предоставлен как часть сообщения с ответом выдачи (например, как часть удостоверяющих данных).

[0128] Заблокированный статический открытый ключ серверного компьютера может быть проверен с помощью сертификата серверного компьютера и криптографического объекта nonce. Проверка заблокированного статического открытого ключа компьютера сервера может включать получение подтверждения, что заблокированный статический открытый ключ компьютера сервера соответствует ожидаемому значению. Например, в некоторых случаях второй заблокированный статический открытый ключ серверного компьютера может быть сгенерирован с помощью статического открытого ключа серверного компьютера, включенного в сертификат серверного компьютера, и криптографического объекта nonce, извлеченного из данных ответа. Второй заблокированный статический открытый ключ серверного компьютера затем может быть сравнен с принятым заблокированным статическим открытым ключом серверного компьютера для подтверждения того, что ключи соответствуют. Альтернативно в некоторых случаях принятый заблокированный статический открытый ключ серверного компьютера может быть проверен путем его сравнения с сохраненным заблокированным статическим открытым ключом серверного компьютера. Если ключи соответствуют, компьютер сервера может быть аутентифицирован. Иначе, аутентификация может потерпеть неудачу. В некоторых вариантах осуществления заблокированный статический открытый ключ может быть предоставлен и в незашифрованном тексте, и в зашифрованном тексте сообщения с ответом для обеспечения проверки и предотвращения несанкционированного доступа.

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

[0130] Данные ответа могут также содержать удостоверяющие данные. Удостоверяющие данные могут содержать любые данные, которые предоставлены с серверного компьютера на клиентский компьютер, которые обеспечивают возможность клиентскому компьютеру проведение транзакций (например, платежных транзакций). Примеры удостоверяющих данных могут включать маркеры, PAN или другую информацию о счете, один или более ключей (например, LUK, используемые для генерирования криптограмм, ключ шифрования, заблокированные или незаблокированные статические открытые ключи и т. д.), параметры формирования ключей (например, для формирования SUK, который используется для генерирования криптограммы, совместно используемого секретного ключа, ключа шифрования и т. д.), параметры формирования криптограмм, информацию о цепочке сертификатов, параметры транзакций и любые другие подходящие данные.

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

[0132] В блоке 508 может сохраняться защищенный идентификатор серверного ключа, полученный из данных ответа. Данные ответа могут также содержать защищенный идентификатор серверного ключа, такой как второй защищенный идентификатор серверного ключа, обсуждаемый в процессе 400. Идентификатор серверного ключа, включенный в защищенный идентификатор серверного ключа, как правило идентифицирует серверный открытый ключ (заблокированный или незаблокированный), который предоставлен в сообщении с ответом. Например, в некоторых вариантах осуществления защищенный идентификатор ключа может быть связан с соответствующим серверным открытым ключом и/или сертификатом и серверным компьютером в базе данных. Соответственно, при будущем осуществлении связи с серверным компьютером может использоваться тот же защищенный идентификатор ключа и/или серверный открытый ключ. Например, последующее сообщение с запросом для серверного компьютера может содержать защищенный идентификатор ключа и быть зашифрованным с помощью серверного открытого ключа, как описано в отношении процесса 200.

E. Приведенное в качестве примера первое сообщение с запросом и его обработка

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

[0134] Как показано на фиг. 6, первое сообщение 600 с запросом содержит версию 602 заголовка, случайный идентификатор 604 ключа, одноразовый клиентский открытый ключ 606 (например, кратковременный или заблокированный открытый ключ), связанный с клиентским компьютером, и зашифрованный текст 608 (то есть, зашифрованные данные запроса). Случайный идентификатор 604 ключа мог быть сгенерирован клиентским компьютером вместо серверного компьютера.

[0135] При принятии первого сообщения 600 с запросом серверный компьютер может выбрать пару 610 базовых ключей (также именуемую как пара начальных ключей) с помощью версии 602 заголовка. Как обсуждается выше, разные значения версии заголовка могут соответствовать разным парам базовых ключей, каждая из которых содержит базовый открытый ключ и базовый закрытый ключ. Пара 610 базовых ключей может использоваться для формирования ключа 612 расшифровки идентификатора, используемого для расшифровки случайного идентификатора 604 ключа. Например, ключ 612 расшифровки идентификатора может формироваться путем точечного умножения базового открытого ключа и базового закрытого ключа пары 610 базовых ключей. Затем серверный компьютер пытается расшифровать случайный идентификатор 604 ключа с помощью ключа 612 расшифровки идентификатора с использованием алгоритма 614 расшифровки для определения идентификатора ключа. Однако, поскольку случайный идентификатор 604 ключа представляет случайное или псевдослучайное значение, в противоположность защищенному идентификатору ключа действительного идентификатора ключа, результатом расшифровки является недействительный идентификатор 616 ключа. Недействительность результата расшифровки приводит к использованию серверным компьютером базового закрытого ключа 618 для расшифровки зашифрованного текста 608 (например, с использованием алгоритма 620 расшифровки). Базовый закрытый ключ 618 может быть частью пары 610 базовых ключей. В некоторых вариантах осуществления может быть более одной пары базовых ключей для разных применений и целей, и базовый закрытый ключ 618, используемый для расшифровки зашифрованного текста 608, может быть частью пары базовых ключей, отличной от пары 610 базовых ключей, используемой для формирования ключа 612 шифрования идентификатора. В некоторых вариантах осуществления одноразовый открытый ключ 606 может использоваться вместе с базовым закрытым ключом 618 для расшифровки зашифрованного текста 608. Варианты осуществления способов обработки первого сообщения 600 с запросом представлены на фиг. 3.

F. Приведенное в качестве примера последующее сообщение с запросом и его обработка

[0136] На фиг. 7 показаны пример последующего сообщения 700 с запросом, отправленного клиентским компьютером на серверный компьютер, и обработка последующего сообщения с запросом серверным компьютером согласно некоторым вариантам осуществления. Сообщение 700 с запросом может быть отправлено после первого сообщения 600 с запросом, показанного на фиг. 6. В промежутке между первым и последующим сообщениями с запросом клиентский компьютер мог уже принять защищенный идентификатор серверного ключа, который представляет действительный идентификатор серверного ключа (например, в сообщении с ответом с серверного компьютера). Таким образом, в отличие от первого сообщения 600 с запросом, последующее сообщение 700 с запросом содержит защищенный идентификатор 704 серверного ключа, который может быть расшифрован для действительного идентификатора серверного ключа (в противоположность недействительному значению). Действительный идентификатор серверного ключа идентифицирует назначенный серверный закрытый ключ для расшифровки зашифрованных данных запроса.

[0137] Как показано на фиг. 7, последующее сообщение 700 с запросом содержит версию 702 заголовка, защищенный идентификатор 704 ключа, одноразовый клиентский открытый ключ 706 (например, кратковременный или заблокированный открытый ключ), связанный с клиентским компьютером, и зашифрованный текст 708 (то есть, зашифрованные данные запроса). Защищенный идентификатор 704 ключа мог быть сгенерирован серверным компьютером (и отправлен на клиентский компьютер в сообщении с ответом или внеполосном канале) вместо клиентского компьютера.

[0138] При принятии сообщения 700 с запросом серверный компьютер может выбрать пару 710 базовых ключей с помощью версии 702 заголовка. Пара 710 базовых ключей может использоваться для формирования ключа 712 расшифровки идентификатора, используемого для расшифровки защищенного идентификатора 704 ключа. Например, ключ 712 расшифровки идентификатора может формироваться путем умножения базового открытого ключа и базового закрытого ключа пары 710 базовых ключей. Затем серверный компьютер пытается расшифровывать защищенный идентификатор 704 ключа с помощью ключа 712 расшифровки идентификатора с использованием алгоритма 714 расшифровки для определения идентификатора 716 ключа и возможных дополнительных данных, таких как заполняющие данные 718 и случайные данные 720. В некоторых вариантах осуществления заполняющие данные 718 могут использоваться для проверки подлинности идентификатора ключа. Например, если заполняющие данные являются такими же, что и элемент постоянных данных, о включении которого с идентификатором ключа в оригинальный защищенный идентификатор ключа известно. Затем наличие заполняющих данных в расшифрованном защищенном идентификаторе ключа может указывать на подлинность и/или целостность идентификатора ключа. В качестве другого примера заполняющие данные 718 могут представлять собой КАС идентификатора 716 ключа, и КАС может быть проверен на подлинность. Случайные данные 720 и/или заполняющие данные могут быть включены для искажения идентификатора ключа и/или приведения защищенного идентификатора ключа, незашифрованных данных, содержащих идентификатор ключа, заполняющие данные и случайное значение, и/или сообщения до фиксированной длины.

[0139] Идентификатор 716 ключа после проверки на подлинность может использоваться для выбора назначенного закрытого ключа 722, который используется для расшифровки зашифрованного текста 708 (например, с применением алгоритма 724 расшифровки). В некоторых вариантах осуществления одноразовый клиентский открытый ключ 706 может использоваться в сочетании с назначенным закрытым ключом 722 для расшифровки зашифрованного текста 708. Варианты осуществления способов обработки последующего сообщения 700 с запросом представлены на фиг. 3.

G. Приведенное в качестве примера сообщение с ответом и его генерирование

[0140] На фиг. 8 показаны пример сообщения 800 с ответом, отправленного серверным компьютером на клиентский компьютер, и генерирование сообщения 800 с ответом согласно некоторым вариантам осуществления. В частности, сообщение 800 с ответом содержит и защищает конфиденциальность нового идентификатора ключа, который идентифицирует новый серверный ключ или ключи (например, пару новых статических серверных закрытого/открытого ключей) для использования в целях последующего осуществления связи. Например, сообщение 800 с ответом может генерироваться серверным компьютером после принятия первого сообщения 600 с запросом, представленного на фиг. 6, или последующего сообщения 700 с запросом, представленного на фиг. 7.

[0141] Сообщение 800 с ответом может содержать версию 802 заголовка, которая идентифицирует номер версии, связанный с парой 810 базовых ключей. Пара 810 базовых ключей может использоваться для формирования ключа 812 шифрования идентификатора подобным образом, как описано со ссылкой на фиг. 6–7. Например, ключ 812 шифрования идентификатора может формироваться путем умножения базового закрытого ключа и базового открытого ключа пары 810 базовых ключей. Ключ 812 шифрования идентификатора может использоваться для шифрования идентификатора 816 серверного ключа и других связанных данных (например, заполняющих данных 818 и случайных данных 820) посредством алгоритма 814 шифрования для получения защищенного идентификатора 804 ключа.

[0142] Идентификатор 816 ключа идентифицирует пару новых серверных ключей, содержащую закрытый ключ 822a и открытый ключ или сертификат 822b. В некоторых вариантах осуществления заполняющие данные могут представлять собой элемент постоянных данных. Наличие элемента постоянных данных в результате расшифровки защищенного идентификатора ключа может указывать на действительность или целостность идентификатора ключа. В некоторых других вариантах осуществления заполняющие данные могут содержать КАС идентификатора 816 ключа или другие аутентификационные данные, которые могут использоваться для проверки подлинности и/или целостности идентификатора 816 ключа. Случайные данные 820 могут гарантировать то, что защищенный идентификатор ключа постоянно изменяется. В некоторых вариантах осуществления заполняющие данные 818 и/или случайные данные 820 могут использоваться для приведения размера защищенного идентификатора 804 ключа, незашифрованных данных, содержащих идентификатор ключа, заполняющие данные и случайное значение, или сообщению фиксированной длины для обеспечения дополнительной безопасности данных.

[0143] Данные ответа, содержащие защищенный идентификатор 804 ключа и новый открытый ключ или сертификат 822b, могут быть зашифрованы с помощью нового закрытого ключа 822a для генерирования зашифрованного текста 808. В некоторых вариантах осуществления включение нового защищенного идентификатора ключа может исключить повторение значения защищенного идентификатора ключа в нескольких сообщениях (например, в сообщениях с запросом и ответом), которое может привести к отслеживанию защищенного идентификатора ключа между сообщениями. Даже при включении одного и того же идентификатора ключа случайное значение 820 может быть изменено так, чтобы генерировать отличающийся защищенный идентификатор 804 ключа.

[0144] В некоторых случаях данные запроса могут также содержать другие данные, которые необходимо зашифровать, такие как удостоверяющие данные. Зашифрованный текст 808 включен в сообщение 800 с ответом. Сообщение 800 с ответом также содержит одноразовый открытый ключ 806, который соответствует новому открытому ключу или сертификату 822b. Например, если открытый ключ 822b представляет собой статический ключ, одноразовый открытый ключ 806 может представлять собой заблокированную форму статического открытого ключа 822b. Альтернативно, если открытый ключ 822b представляет собой кратковременный ключ, одноразовый открытый ключ 806 может быть таким же, что и кратковременный открытый ключ 822b.

H. Приведенные в качестве примера сообщения с запросом и ответом с идентификатором клиентского ключа

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

[0146] Для каждой пары запрос/ответ клиентский компьютер генерирует защищенный идентификатор клиентского ключа (случайный идентификатор запроса) или любое одноразовое значение, которое не раскрывает повторно используемые биты. Защищенный идентификатор клиентского ключа зашифрован и включен в зашифрованный текст сообщения с запросом.

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

[0148] На фиг. 9 показано приведенное в качестве примера сообщение 900 с запросом и приведенное в качестве примера сообщение 920 с ответом, которые содержат защищенный идентификатор клиентского ключа согласно некоторым вариантам осуществления. Сообщение 900 с запросом может отправляться клиентским компьютером на серверный компьютер, и сообщение 920 с ответом может отправляться серверным компьютером на клиентский компьютер.

[0149] Как показано на фиг. 9, сообщение с запросом 900 содержит защищенный идентификатор 908 клиентского ключа в зашифрованном тексте 918 сообщения. Например, идентификатор 908 клиентского ключа может быть зашифрован с помощью ключа сеанса запроса для включения в зашифрованный текст. В некоторых вариантах осуществления включение защищенного идентификатора ключа в зашифрованный текст может защищать конфиденциальность идентификатора клиентского ключа. Защищенный идентификатор 908 клиентского ключа может быть сгенерирован или определен клиентским компьютером и связан с клиентским закрытым ключом или парой клиентских ключей, которые используются для защиты сообщения с запросом. Например, защищенный идентификатор 908 клиентского ключа может быть связан с парой одноразовых клиентских ключей (например, парой кратковременных ключей), содержащей одноразовый клиентский закрытый ключ и одноразовый клиентский открытый ключ. Одноразовый клиентский закрытый ключ может использоваться (например, совместно с серверным открытым ключом) для генерирования совместно используемого секретного ключа запроса, который используется для шифрования данных запроса с целью получения зашифрованного текста 918. Одноразовый клиентский открытый ключ может быть предоставлен в незашифрованном тексте 916 сообщения 900 с запросом в исходном или в искаженном виде (показан как одноразовый клиентский открытый ключ 906 на фиг. 9) так, чтобы серверный компьютер мог расшифровать сообщение с помощью клиентского открытого ключа (например, совместно с серверным закрытым ключом).

[0150] Сообщение 900 с запросом может также содержать другие данные, обсуждаемые в данном документе. Например, незашифрованный текст 916 сообщения 900 с запросом может содержать версию 902 заголовка и защищенный идентификатор 904 серверного ключа, подобные тем, что обсуждаются выше со ссылкой на фиг. 7. Сообщение 900 с запросом может дополнительно содержать зашифрованные данные 910 протокола (например, информацию о наборе шифров, информацию об отображении данных и т. д.) и зашифрованные полезные данные 912 (например, клиентские аутентификационные данные). Аутентификационные данные 919 сообщения 900 с запросом могут содержать один или более кодов 914 аутентификации сообщений (КАС) для всех данных запроса и/или их частей.

[0151] Как показано на фиг. 9, сообщение 920 с ответом содержит защищенный идентификатор 924 клиентского ключа в незашифрованном тексте 936 сообщения 920 с ответом. Защищенный идентификатор 924 клиентского ключа мог быть принят серверным компьютером в предыдущем сообщении с запросом, подобном сообщению 900 с запросом. Включение защищенного идентификатора 924 клиентского ключа обеспечивает возможность клиентскому компьютеру отобразить сообщение 920 с ответом в соответствующее сообщение с запросом (например, сообщение 900 с запросом) и выбрать подходящий клиентский закрытый ключ для расшифровки сообщения 920 с ответом.

[0152] Сообщение 920 с ответом может также содержать другие данные, обсуждаемые в данном документе. Например, незашифрованный текст 936 сообщения 920 с ответом может содержать версию 922 заголовка и одноразовый серверный открытый ключ 926, подобные тем, что обсуждаются выше со ссылкой на фиг. 8. Зашифрованный текст 938 сообщения 920 с ответом может дополнительно содержать данные 928 протокола и полезные данные 932. Данные 928 протокола могут содержать защищенный идентификатор 930 серверного ключа, который идентифицирует серверные закрытый/открытый ключи. Серверный закрытый ключ используется для шифрования данных ответа для получения зашифрованного текста 938. Защищенный идентификатор 930 серверного ключа может передаваться обратно на серверный компьютер в последующем сообщении с запросом для обеспечения серверному компьютеру возможности расшифровки сообщения с запросом. Серверный открытый ключ предоставляется (как одноразовый серверный открытый ключ 926) в исходном или в искаженном виде. Полезные данные 932 могут содержать удостоверяющие данные, предоставленные на клиентский компьютер, данные приложения или любые другие подходящие данные, предназначенные для клиентского компьютера. Аутентификационные данные 939 сообщения 920 с ответом могут содержать один или более кодов 934 аутентификации сообщений (КАС) для всех данных ответа и/или их частей.

III. Способы защиты данных

[0153] Согласно вариантам осуществления защищаются данные протокола, используемые для шифрования/расшифровки полезных данных, отдельно от полезных данных. Закрытые полезные данные могут быть зашифрованы с помощью одного или более ключей шифрования полезных данных для генерирования зашифрованных полезных данных. Данные протокола, содержащие набор шифров, используемый для шифрования полезных данных, могут также быть зашифрованы с помощью одного или более ключей шифрования протокола. Ключи шифрования протокола и ключи шифрования полезных данных могут быть установлены на основе согласования ключей. Зашифрованные данные протокола и зашифрованные полезные данные могут быть отправлены в сообщении.

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

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

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

A. Способы шифрования сообщения

[0157] На фиг. 10 показан приведенный в качестве примера процесс 1000 шифрования сообщения согласно некоторым вариантам осуществления. Процесс 1000 может быть реализован клиентским компьютером для шифрования сообщения с запросом для серверного компьютера. Альтернативно процесс 1000 может быть также реализован серверным компьютером для шифрования сообщения с ответом для клиентского компьютера.

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

[0159] Набор шифров может быть определен клиентским компьютером или серверным компьютером на основе предопределенных параметров, таких как аппаратные/программные конфигурации и возможности (например, операционная система, память, ЦП), предопределенные предпочтения (например, предпочтения пользователя) и тому подобное. Дополнительно набор шифров может быть определен на основе согласования между клиентским компьютером и серверным компьютером. Например, клиентский компьютер может отправлять поддерживаемый список наборов шифров на серверный компьютер в запросе. Наборы шифров могут быть перечислены в порядке предпочтения клиентского компьютера. Например, первый набор шифров в списке наборов шифров может быть наиболее предпочтительным для клиентского компьютера, второй набор шифров может быть менее предпочтительным для клиентского компьютера, чем первый набор шифров, и т. д. Сообщение с запросом может не содержать никаких полезных данных. Альтернативно сообщение с запросом может содержать полезные данные, которые зашифрованы с помощью предпочтительного набора шифров. В ответ серверный компьютер может выбрать набор шифров из списка наборов шифров, предоставленного клиентским компьютером (который может быть или не быть набором шифров, предпочтительным для клиентского компьютера), и содержать выбранный набор шифров в сообщении с ответом. Сообщение с ответом может не содержать никаких полезных данных. Альтернативно сообщение с ответом может содержать полезные данные, которые зашифрованы или иным образом закодированы с помощью выбранного набора шифров.

[0160] В блоке 1004 определяется один или более ключей шифрования протокола и один или более ключей шифрования полезных данных. Ключи шифрования протокола и ключи шифрования полезных данных могут быть определены на основе одного или более совместно используемых секретных ключей между отправителем и получателем сообщения, KDF и/или параметров формирования ключей. Совместно используемые секретные ключи могут быть сформированы с помощью одного или более закрытых ключей отправителя (например, клиентского закрытого ключа или серверного закрытого ключа) и одного или более открытых ключей получателя (например, серверного открытого ключа или клиентского открытого ключа). Совместно используемые секретные ключи могут быть сформированы с помощью любого подходящего алгоритма согласования ключей, такого как ECDH. В варианте осуществления один закрытый ключ может быть объединен с разными открытыми ключами для формирования разных совместно используемых секретных ключей. В другом варианте осуществления разные закрытые ключи могут быть объединены с одним открытым ключом для формирования разных совместно используемых секретных ключей. Закрытый и открытый ключи могут представлять собой одноразовые ключи, такие как кратковременные ключи или заблокированные статические ключи. Открытый ключ получателя может быть получен из предыдущего сообщения получателя или из внеполосного канала, такого как электронная почта, текст, телефонный вызов, почтовая связь, или любого другого канала, который отличается от текущего канала связи для сообщений с запросом/ответом. В некоторых случаях открытый ключ получателя может быть получен от третьей стороны, такой как орган сертификации.

[0161] Ключи шифрования протокола и/или ключи шифрования полезных данных могут генерироваться на основе набора шифров в дополнение к совместно используемым секретным ключам или вместо них. Например, набор шифров может указывать размеры ключей для генерирования и/или алгоритмы генерирования ключей (например, KDF).

[0162] Ключи шифрования протокола и/или ключи шифрования полезных данных могут генерироваться из одного и того же или разных совместно используемых секретных ключей (ключа). В одном примере совместно используемый секретный ключ используется в качестве входных данных для функции формирования ключа (KDF) для генерирования длинной строки битов, которая разбивается на различные более короткие подстроки. Подстроки затем могут использоваться для генерирования ключей шифрования протокола и/или ключей шифрования полезных данных. Например, первая и вторая подстроки могут использоваться как ключи шифрования протокола, а остальные подстроки могут использоваться как ключи шифрования полезных данных. В другом примере разные совместно используемые секретные ключи могут использоваться с одними и теми же или разными KDF для генерирования разных ключей.

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

[0164] Ключи шифрования протокола и/или ключи шифрования полезных данных могут генерироваться независимо друг от друга или на основе предварительно сгенерированных ключей. Например, ключ шифрования протокола может использоваться в качестве входных данных для генерирования другого ключа шифрования протокола или ключа шифрования полезных данных. Ключ шифрования полезных данных может использоваться в качестве входных данных для генерирования другого ключа шифрования полезных данных.

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

[0166] В некоторых вариантах осуществления полезные данные могут быть зашифрованы как одно целое с помощью ключа шифрования полезных данных и алгоритма шифрования, указанного набором шифров. Например, полезные данные, ключ шифрования полезных данных и необязательно заголовок (например, защищенный идентификатор ключа получателя, одноразовый открытый ключ отправителя) могут использоваться в качестве входных данных в функцию AEAD для получения зашифрованного текста (зашифрованных полезных данных) и метки аутентификации (кода аутентификации сообщений (КАС)).

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

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

[0169] Кроме информации о наборе шифров, данные протокола могут также содержать дополнительные данные, такие как данные дескриптора безопасности данных, описывающие то, как зашифровывать отдельные элементы данных. Данные дескриптора могут содержать информацию об отображении данные-протокол. Например, для каждого элемента полезных данных информация об отображении данные-протокол может содержать детальную информацию протокола, характерную для элемента, для данного элемента полезных данных, такую как метка данных, идентификатор ключа шифрования/расшифровки, идентификатор алгоритма шифрования/расшифровки и тому подобное. В некоторых вариантах осуществления информация протокола, характерная для элемента, может необязательно содержать код аутентификации сообщений, связанный с элементом полезных данных (например, в результате применения AEAD к элементу полезных данных). Отображения данные-протокол могут быть сохранены в таблице, списке, файле, базе данных или любой другой структуре данных или хранилище данных, которое доступно для отправителя сообщения.

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

[0171] Данные протокола могут быть зашифрованы с помощью ключей шифрования протокола, определенных в блоке 1004. В некотором варианте осуществления данные протокола могут быть зашифрованы с помощью одного ключа шифрования протокола (например, сформированного из закрытого ключа отправителя и одноразового открытого ключа получателя или одноразового закрытого ключа отправителя и открытого ключа получателя). В некоторых других вариантах осуществления разные части данных протокола могут быть зашифрованы с помощью разных ключей шифрования протокола и/или алгоритмов шифрования. Например, отображения данные-протокол данных протокола могут быть зашифрованы с помощью одного или более ключей шифрования отображения и/или алгоритма (-ов) шифрования (например, AEAD), характерных для отображений данные-протокол; при этом набор шифров данных протокола может быть зашифрован с помощью одного или более ключей шифрования набора шифров и предопределенного алгоритма шифрования (например, AES).

[0172] В блоке 1010 сообщение, содержащее зашифрованные полезные данные и зашифрованные данные протокола, может быть передано получателю сообщения. Например, сообщение может представлять собой сообщение с запросом, передаваемое клиентским компьютером на серверный компьютер, или сообщение с ответом, передаваемое серверным компьютером на клиентский компьютер.

[0173] Зашифрованные полезные данные и зашифрованные данные протокола могут быть включены в часть сообщения с зашифрованным текстом. Сообщение может содержать дополнительную информацию в части сообщения с незашифрованным текстом. Например, сообщение может содержать защищенный идентификатор ключа получателя (например, защищенный идентификатор серверного ключа в сообщении с запросом или защищенный идентификатор клиентского ключа в сообщении с ответом) в незашифрованном тексте для обеспечения получателю возможности идентификации закрытого ключа получателя, используемого для расшифровки сообщения. Сообщение может также содержать одноразовый открытый ключ отправителя (например, одноразовый клиентский открытый ключ в сообщении с запросом или одноразовый серверный открытый ключ в сообщении с ответом), который может представлять собой кратковременный ключ или заблокированный статический ключ. Сообщение может также содержать версию заголовка, указывающую версию протокола, который может использоваться получателем сообщения, например, для определения подходящего идентификатора ключа шифрования/расшифровки для расшифровки защищенного идентификатора ключа получателя. Подлинность некоторой или всей дополнительной информации, вместе с данными протокола и полезными данными, может быть защищена с помощью алгоритма аутентификации (например, AEAD) для генерирования глобального КАС, который включен в сообщение. В одном примере глобальный КАС может генерироваться с помощью того же ключа, что и ключ шифрования протокола (например, ключ шифрования набора шифров или ключ шифрования отображения). В некоторых вариантах осуществления глобальный КАС может вычисляться из КАС, характерных для элементов полезных данных, вместо зашифрованных элементов полезных данных или в дополнение к ним. Это обеспечивает гибкость при аутентификации заголовка сообщения, когда элементы данных полезных данных рассеяны (например, не расположены последовательным образом) в сообщении или документе. КАС, характерные для элементов полезных данных, могут также быть включены как часть отображений данные-протокол или в другом подходящем месте внутри сообщения.

[0174] На фиг. 11 показан другой приведенный в качестве примера процесс 1100 шифрования сообщения согласно некоторым вариантам осуществления. Процесс 1100 может быть реализован клиентским компьютером для шифрования сообщения с запросом для серверного компьютера. Альтернативно процесс 1100 может быть также реализован серверным компьютером для шифрования сообщения с ответом для клиентского компьютера.

[0175] В блоке 1102 один или более совместно используемых секретных ключей определяются с помощью одного или более закрытых ключей отправителя и одного или более открытых ключей получателя. Совместно используемые секретные ключи могут быть сформированы с помощью любого подходящего алгоритма согласования ключей, такого как ECDH. Для сообщения с запросом совместно используемый секретный ключ запроса может определяться с помощью клиентского закрытого ключа и серверного открытого ключа. Для сообщения с ответом совместно используемый секретный ключ ответа может определяться с помощью серверного закрытого ключа и клиентского открытого ключа. Закрытые ключи и/или открытые ключи могут представлять собой одноразовые ключи (например, кратковременные ключи или статические заблокированные ключи).

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

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

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

[0179] В блоке 1106 набор шифров зашифровывается с помощью первого ключа шифрования протокола (также именуемого как ключ шифрования набора шифров) для получения зашифрованного набора шифров. Набор шифров может быть определен так, как описано в блоке 1002 процесса 1000, представленного на фиг. 10. Ключ шифрования набора шифров выбирается из множества ключей сеанса, определенных в блоке 1104. Ключ шифрования набора шифров и/или алгоритм шифрования, используемый для шифрования набора шифров, как правило не зависят от самого набора шифров. Например, набор шифров может определять использование алгоритма шифрования AEAD и размер ключа 256 бит для шифрования полезных данных. Ключ шифрования набора шифров может быть другого размера (например, 128 бит), и алгоритм шифрования для шифрования набора шифров может представлять собой улучшенный стандарт шифрования (AES). В некоторых вариантах осуществления зашифрованный набор шифров может быть включен как часть незашифрованного текста сообщения. В других вариантах осуществления зашифрованный набор шифров может быть включен как часть зашифрованного текста сообщения.

[0180] В блоке 1108 каждый из множества элементов полезных данных шифруют с помощью соответствующего ключа шифрования полезных данных. Ключи шифрования полезных данных могут быть получены из множества ключей сеанса, определенных в блоке 1104. Полезные данные могут быть разделены на множество элементов полезных данных по различным причинам. Например, разделение полезных данных на меньшие отдельно защищенные элементы данных может снижать риск раскрытия всех полезных данных, если один из ключей шифрования полезных данных раскрыт. Альтернативно каждый из элементов данных может быть предназначен для осуществления доступа к нему разными субъектами или связан с разными уровнями безопасности. Защита элементов данных разными ключами и/или алгоритмами шифрования может, таким образом, ограничивать доступ данных сторон к предназначенным элементам данных без необходимости раскрытия других элементов данных.

[0181] Ключи шифрования набора шифров могут быть получены из множества ключей сеанса, сформированных в блоке 1104 выше. По существу, ключи шифрования набора шифров могут быть определены на основе совместно используемого секретного ключа (ключей), определенного в блоке 1102. Альтернативно или дополнительно ключи шифрования набора шифров могут быть определены на основе одного или более ключей шифрования протокола или других данных.

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

[0183] В некоторых вариантах осуществления набор шифров может определять некоторые, но не все параметры, управляющие шифрованием элементов полезных данных. Например, набор шифров может определять необходимость использования алгоритма AEAD без определения размера ключа. Альтернативно набор шифров может определять только размер ключа без определения алгоритма шифрования. В таких вариантах осуществления элементы полезных данных могут быть зашифрованы с помощью алгоритма шифрования, характерного для элемента и/или размера ключа шифрования полезных данных. Данная информация о шифровании, характерная для элемента, может быть включена в информацию описания, характерную для элемента, (например, информацию об отображении данные-протокол) как часть данных протокола.

[0184] Алгоритм шифрования, размер ключа и/или другие аспекты, связанные с шифрованием элемента полезных данных, могут определяться на основе различных факторов, таких как тип элемента полезных данных (например, объект мультимедиа или текстовый файл), размер элемента полезных данных, уровень секретности или безопасности, связанный с элементом полезных данных, и других характеристик полезных данных. Факторы могут также включать характеристики назначенного принимающего субъекта (например, пользователя, компьютера или процесса) для элемента полезных данных, такие как сущность, уровень управления доступом, сетевая среда (например, безопасная или небезопасная), аппаратные возможности (например, сетевые или вычислительные ресурсы), программные конфигурации (например, операционная система или приложения) и тому подобное.

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

[0186] Отображения данные-протокол могут содержать множество элементов отображения, соответственно соответствующих множеству элементов полезных данных. Каждый элемент отображения может содержать ссылку на элемент полезных данных (например, метку данных), идентификатор ключа, который идентифицирует ключ шифрования/расшифровки для элемента полезных данных, идентификатор алгоритма, который идентифицирует криптографический алгоритм (например, алгоритм шифрования/расшифровки) для элемента полезных данных (например, AEAD), код аутентификации сообщений (КАС) для элемента полезных данных и тому подобное. КАС может генерироваться в результате применения алгоритма шифрования (например, AEAD) к элементу полезных данных. Некоторые или все указанные выше данные элементов отображения могут быть необязательными в разных вариантах осуществления. Например, элемент отображения может содержать только КАС для данного элемента полезных данных без включения идентификатора ключа шифрования/расшифровки или идентификатора алгоритма. Таким образом, отображения данные-протокол могут содержать только список элементов данных КАС. В качестве другого примера элемент отображения может содержать идентификатор ключа шифрования/расшифровки и/или идентификатор алгоритма, но может не содержать КАС. Например, алгоритм шифрования (например, AES) может не генерировать КАС при применении к элементу полезных данных.

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

[0188] В блоке 1112 передается сообщение, содержащее зашифрованный набор шифров, зашифрованные отображения данные-протокол и зашифрованные элементы полезных данных. Например, сообщение может представлять собой сообщение с запросом, передаваемое клиентским компьютером на серверный компьютер, или сообщение с ответом, передаваемое серверным компьютером на клиентский компьютер.

[0189] Зашифрованные полезные данные и зашифрованные данные протокола могут быть включены в часть сообщения с зашифрованным текстом. Альтернативно некоторые из зашифрованных данных протокола (например, зашифрованный набор шифров) могут быть включены в часть сообщения с незашифрованным текстом. Сообщение может содержать дополнительные данные, такие как защищенный идентификатор ключа получателя (например, защищенный идентификатор серверного ключа в сообщении с запросом или защищенный идентификатор клиентского ключа в сообщении с ответом) для обеспечения получателю возможности идентификации закрытого ключа получателя, используемого для расшифровки сообщения. Сообщение может также содержать одноразовый открытый ключ отправителя (например, одноразовый клиентский открытый ключ в сообщении с запросом или одноразовый серверный открытый ключ в сообщении с ответом), который может представлять собой кратковременный ключ или заблокированный статический ключ. Сообщение может также содержать версию заголовка, указывающую на версию протокола, которая может использоваться получателем сообщения, например, для определения подходящего идентификатора ключа шифрования/расшифровки для расшифровки защищенного идентификатора серверного ключа. Подлинность некоторой или всей этой дополнительной информации может быть включена в часть с незашифрованным текстом или часть с зашифрованным текстом сообщения. Данные, включенные в часть сообщения с незашифрованным текстом, могут не зашифровываться, но при этом обеспечена защита подлинности/целостности (например, посредством AEAD). Таким образом, сообщение может не только содержать КАС для отдельных элементов полезных данных, но также один или более глобальных КАС, которые защищают данные в форме незашифрованного текста, включенные в сообщение.

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

B. Способы расшифровки сообщения

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

[0192] В блоке 1202 принимается сообщение, содержащее зашифрованные данные протокола и зашифрованные полезные данные. В некоторых вариантах осуществления сообщение могло быть сгенерировано способом шифрования сообщения, описанным со ссылкой на фиг. 10–11 выше.

[0193] В блоке 1204 определяются один или более ключей расшифровки протокола. Ключи расшифровки протокола могут быть такими же как и соответствующие ключи шифрования протокола, описанные со ссылкой на фиг. 10–11, или отличаться от них. Ключи расшифровки протокола могут быть определены на основе одного или более совместно используемых секретных ключей между отправителем и получателем сообщения, KDF и параметров формирования ключей, при их наличии. Например, совместно используемые секретные ключи могут быть сформированы с помощью одного или более закрытых ключей получателя (например, клиентского закрытого ключа или серверного закрытого ключа) и одного или более открытых ключей отправителя (например, серверного открытого ключа или клиентского открытого ключа). Совместно используемые секретные ключи могут быть сформированы с помощью любого подходящего алгоритма согласования ключей, такого как ECDH. Закрытый и открытый ключи могут представлять собой одноразовые ключи, такие как кратковременные ключи или заблокированные статические ключи.

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

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

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

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

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

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

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

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

[0202] В блоке 1208 определяется один или более ключей расшифровки полезных данных. Ключи расшифровки полезных данных могут быть теми же или отличаться от соответствующих ключей шифрования полезных данных, описанных со ссылкой на фиг. 10–11. Ключи расшифровки протокола могут быть определены на основе одного или более совместно используемых секретных ключей между отправителем и получателем сообщения подобным образом, как описано в блоке 1204. В некоторых вариантах осуществления один и тот же совместно используемый секретный ключ используется для генерирования как ключей расшифровки протокола, так и ключей расшифровки полезных данных. Альтернативно разные совместно используемые секретные ключи могут использоваться для генерирования ключей расшифровки протокола и ключей расшифровки полезных данных.

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

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

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

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

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

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

[0209] Расшифрованные полезные данные могут обрабатываться любым подходящим образом получателем сообщения. Например, сообщение может представлять собой сообщение с ответом предоставления с серверного компьютера, и полезные данные сообщения могут содержать удостоверяющие данные (например, PAN или маркер, ключи ограниченного использования), которые предоставляются на клиентский компьютер. Клиентский компьютер может затем использовать удостоверяющие данные для проведения транзакций. В качестве другого примера, сообщение может представлять собой сообщение с запросом с клиентского компьютера на серверный компьютер, и полезные данные сообщения могут содержать аутентификационные или идентификационные данные клиентского компьютера. Полезные данные могут использоваться серверным компьютером для аутентификации клиентского компьютера и/или для генерирования соответствующего ответа.

[0210] В некоторых вариантах осуществления некоторые или все расшифрованные полезные данные могут повторно зашифровываться с помощью другого ключа шифрования (например, совместно используемого или закрытого), хранимого в хранилище данных, и/или передаваться другому субъекту.

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

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

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

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

[0215] В блоке 1306 ключ расшифровки набора шифров определяется на основе совместно используемого секретного ключа или секретных ключей, определенных выше. Например, совместно используемый секретный ключ может использоваться в качестве входных данных в KDF для генерирования строки битов, часть которой (например, первые 128 битов) может использоваться как ключ расшифровки набора шифров. Ключ расшифровки набора шифров представляет собой ключ расшифровки протокола. Остальная часть строки может разбиваться для генерирования других ключей расшифровки протокола (например, ключа расшифровки отображения) или ключей расшифровки полезных данных.

[0216] В блоке 1308 зашифрованный набор шифров расшифровывается с помощью ключа расшифровки набора шифров для получения набора шифров. Ключ расшифровки набора шифров и/или алгоритм расшифровки, используемые для расшифровки набора шифров, как правило, не зависят от самого набора шифров. Например, набор шифров может определять использование алгоритма шифрования AEAD и размер ключа 256 бит. Ключ расшифровки набора шифров может быть разного размера (например, 128 бит), и алгоритм расшифровки для расшифровки набора шифров (например, улучшенный стандарт шифрования (AES)) может отличаться от того, который определен набором шифров. В некоторых вариантах осуществления зашифрованный набор шифров может быть включен как часть незашифрованного текста сообщения. В других вариантах осуществления зашифрованный набор шифров может быть включен как часть зашифрованного текста сообщения.

[0217] В блоке 1310 определяется ключ расшифровки отображения с помощью совместно используемого секретного ключа (ключей), определенного в блоке 1304. Ключ расшифровки отображения представляет собой данные расшифровки протокола, которые используются для расшифровки дополнительных данных протокола, таких как отображения данные-протокол, представленные ниже. Ключ расшифровки отображения, как правило, отличается от ключа расшифровки набора шифров. Однако в некоторых случаях ключ расшифровки отображения может быть таким же, как и ключ расшифровки набора шифров. В некоторых вариантах осуществления ключ расшифровки отображения может быть определен с помощью одного и того же совместно используемого секретного ключа, который используется для определения ключа расшифровки набора шифров. В других вариантах осуществления ключ расшифровки отображения может определяться с помощью совместно используемого секретного ключа, отличающегося от того, что используется для определения ключа расшифровки набора шифров. Ключ расшифровки отображения может быть определен по существу в одно и то же время или в другое время по сравнению с ключом расшифровки набора шифров.

[0218] В некоторых вариантах осуществления ключ расшифровки отображения может определяться по меньшей мере частично на основе набора шифров. Например, размер ключа расшифровки отображения и/или KDF может определяться набором шифров. Соответственно, участок строки битов с соответствующим размером выбирается в качестве ключа расшифровки отображения. Строка битов может быть выводимой строкой KDF на основе совместно используемого секретного ключа. В некоторых случаях другие участки одной и той же выводимой строки могут использоваться для ключа расшифровки набора шифров и/или ключей расшифровки полезных данных. В других вариантах осуществления ключ расшифровки отображения может не основываться на наборе шифров.

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

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

[0221] Отображения данные-протокол могут содержать множество элементов отображения, соответственно соответствующих множеству элементов полезных данных. Каждый элемент отображения может содержать ссылку на элемент полезных данных (например, метку данных), идентификатор ключа, который идентифицирует ключ шифрования/расшифровки для элемента полезных данных, идентификатор алгоритма, который идентифицирует криптографический алгоритм (например, алгоритм шифрования/расшифровки) для элемента полезных данных (например, AEAD), код аутентификации сообщений (КАС) для элемента полезных данных и тому подобное. КАС может генерироваться в результате применения алгоритма шифрования (например, AEAD) к элементу полезных данных. Некоторые или все указанные выше данные элементов отображения могут быть необязательными в разных вариантах осуществления. Например, элемент отображения может содержать только КАС для данного элемента полезных данных без включения идентификатора ключа шифрования/расшифровки или идентификатора алгоритма. Таким образом, отображения данные-протокол могут содержать список КАС. В качестве другого примера элемент отображения может содержать идентификатор ключа шифрования/расшифровки и/или идентификатор алгоритма, но может не содержать КАС. Например, алгоритм шифрования (например, AES) может не генерировать КАС при применении к элементу полезных данных.

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

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

[0224] Один или более ключей расшифровки полезных данных могут определяться на основе совместно используемого секретного ключа (ключей), определяемого в блоке 1304. Ключи расшифровки полезных данных могут генерироваться с помощью одного и того же совместно используемого секретного ключа (ключей) и/или одной и той же KDF как для ключей расшифровки протокола (например, ключа набора шифров и/или ключа расшифровки отображения), описанных выше. В варианте осуществления длинная строка битов генерируется посредством KDF с помощью совместно используемого секретного ключа. Длинные строки битов разбиваются на множество меньших подстрок, каждая из которых соответствует ключу расшифровки полезных данных. Длинная строка битов может также использоваться для генерирования ключа расшифровки набора шифров и/или ключа расшифровки отображения в некоторых вариантах осуществления.

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

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

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

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

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

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

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

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

[0233] Сообщение 1400 может содержать дополнительные аутентифицированные данные (AAD) 1418, зашифрованный текст 1420 и аутентификационные данные 1422. AAD 1418 могут содержать версию 1402 заголовка, один или более защищенных идентификаторов 1404 ключей получателя и один или более одноразовых открытых ключей 1406 отправителя. Версия 1402 заголовка может указывать версию протокола, используемую текущим сообщением. В некоторых вариантах осуществления версия заголовка может не быть включена в AAD 1418, а вместо этого оставаться в незашифрованном виде. Версия протокола может устанавливать формат данных сообщения. Защищенные идентификаторы 1404 ключей получателя могут представлять собой защищенные идентификаторы серверных ключей для сообщения с запросом и защищенные идентификаторы клиентских ключей для сообщения с ответом. Каждый защищенный идентификатор ключа получателя может использоваться для идентификации соответствующего закрытого ключа получателя. Одноразовые открытые ключи 1406 отправителя могут содержать один или более одноразовых клиентских открытых ключей для сообщения с запросом или один или более одноразовых серверных открытых ключей для сообщения с ответом. Одноразовые открытые ключи 1406 отправителя могут представлять собой кратковременные ключи или заблокированные или искаженные статические ключи. Данные, включенные в AAD, могут не зашифровываться, но могут быть искажены и защищены в отношении целостности (например, посредством примененной глобальной функции AEAD). Например, одноразовые открытые ключи 1406 отправителя могут быть искажены. Защищенный идентификатор ключа получателя может быть включен в защищенной форме (например, зашифрованной). Версия 1402 заголовка может быть предоставлена в обычном и неискаженном или зашифрованном виде.

[0234] Зашифрованный текст 1420 может содержать зашифрованные полезные данные 1414 и зашифрованные данные протокола, содержащие зашифрованный набор 1408 шифров, и другие зашифрованные данные 1410 протокола, содержащие дескриптор 1412 безопасности данных. Дескриптор 1412 безопасности данных может содержать отображения данные-протокол, такие как описанные в данном документе.

[0235] Аутентификационные данные 1422 могут содержать один или более кодов шифрования сообщений (например, AEAD КАС) для всего сообщения и/или для различных частей сообщения. Например, аутентификационные данные 1422 могут содержать глобальный КАС, который защищает AAD 1418, и/или множество локальных КАС, каждый из которых защищает разную часть сообщения, такую как разный элемент полезных данных полезных данных.

[0236] После принятия сообщения 1400 получателем (например, серверным компьютером или клиентским компьютером) получателем могут быть приняты следующие приведенные в качестве примера этапы для расшифровки сообщения согласно вариантам осуществления.

[0237] На этапе 1 может быть определен базовый закрытый ключ 1424 получателя. Определение может происходить на основе версии 1402 заголовка. Например, может существовать множество базовых закрытых ключей, связанных с разными версиями протокола. Версия 1402 заголовка может указывать версию протокола сообщения и, следовательно, использоваться для выбора соответствующего базового закрытого ключа.

[0238] На этапе 2 ключ 1426 расшифровки идентификатора может формироваться на основе базового закрытого ключа 1424. Например, ключ 1426 расшифровки идентификатора может формироваться на основе точечного умножения базового закрытого ключа 1424 и базового открытого ключа, связанного с базовым закрытым ключом 1424. Ключ 1426 расшифровки идентификатора может использоваться для расшифровки одного или более защищенных идентификаторов 1402 ключей получателя для получения одного или более идентификаторов ключей получателя (не показано).

[0239] На этапе 3 один или более идентификаторов ключей получателя используются для извлечения соответствующих закрытых ключей 1428 получателя. В некоторых случаях, когда идентификатор ключа получателя является недействительным (например, случайным идентификатором, который не связан с каким-либо закрытым ключом получателя), базовый закрытый ключ или какой-либо другой подходящий закрытый ключ может использоваться вместо него.

[0240] На этапе 4 один или более совместно используемых секретных ключей генерируются на основе одного или более закрытых ключей 1428 получателя и одного или более одноразовых открытых ключей 1406 отправителя (например, с помощью ECDH).

[0241] На этапе 5 совместно используемые секретные ключи могут использоваться для формирования одного или более ключей 1430 защиты (также именуемых как ключи сеанса), таких как SK₀, SK₁, … SK_n с помощью KDF и других параметров формирования ключей, при их наличии. Ключи 1430 защиты могут содержать ключи расшифровки протокола и ключи расшифровки полезных данных. В некоторых случаях некоторые или все ключи 1430 расшифровки могут быть такими же как ключи шифрования, используемые для шифрования данных в сообщении. В некоторых других случаях ключи расшифровки могут отличаться от ключей шифрования.

[0242] На этапе 6 первый ключ защиты (SK₀) используется для расшифровки зашифрованного набора 1408 шифров для получения набора шифров. Первый ключ защиты и алгоритм расшифровки для расшифровки набора шифров могут не зависеть от набора шифров.

[0243] На этапе 7 второй ключ защиты (SK₁) используется для расшифровки других зашифрованных данных 1410 протокола для получения дополнительных данных протокола, таких как описание безопасности данных (например, отображения данные-протокол). Расшифровка зашифрованных данных 1410 протокола может осуществляться согласно набору шифров. Например, набор шифров может указывать алгоритм расшифровки для использования (например, AEAD).

[0244] На этапе 8 другие ключи защиты (например, SK₃ – SK_n) и данные протокола используются для расшифровки зашифрованных полезных данных 1414. Например, зашифрованные полезные данные могут содержать множество независимо зашифрованных элементов данных. Отображения данные-протокол могут использоваться теперь для определения расшифровки и/или проверки подлинности каждого зашифрованного элемента данных путем определения ключа расшифровки полезных данных, алгоритма расшифровки и/или кода аутентификации сообщений для использования. Например, в одном примере первый зашифрованный элемент полезных данных может расшифровываться с помощью первого ключа расшифровки полезных данных (например, SK_i), тогда как второй зашифрованный элемент полезных данных может расшифровываться с помощью второго ключа расшифровки полезных данных (например, SK_i). В некоторых случаях некоторые или все зашифрованные элементы полезных данных могут не расшифровываться или могут расшифровываться в разные моменты времени.

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

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

C. Защита данных для HTTP-сообщений

[0247] Способы, обсужденные в данном документе, может применяться для защиты закрытых данных, передаваемых в HTTP-сообщениях. В некоторых вариантах осуществления закрытые полезные данные могут зашифровываться с помощью способов шифрования, описанных в данном документе, для генерирования зашифрованных данных полезных данных и зашифрованных данных протокола. Зашифрованные данные полезных данных и зашифрованные данные протокола могут быть включены в HTTP-сообщение (например, HTTP-сообщение с запросом или HTTP-сообщение с ответом) и передаваться. С другой стороны, HTTP-сообщение, содержащее зашифрованные данные протокола и зашифрованные полезные данные, может расшифровываться с помощью способов расшифровки, описанных в данном документе, для раскрытия закрытых данных полезных данных. В различных вариантах осуществления закрытые данные полезных данных могут включать файл, объект данных, поток данных или любую другую форму данных.

[0248] Несмотря на то, что в вариантах осуществления в следующем обсуждении применяется нотация объектов JavaScript (JSON) и JSON веб-шифрование (JWE) для осуществления различных аспектов, ясно, что любой другой подходящий формат данных и/или схемы шифрования сообщений могут использоваться в альтернативных вариантах осуществления.

[0249] На фиг. 15 показан приведенный в качестве примера процесс 1500 генерирования HTTP-сообщения с запросом согласно некоторым вариантам осуществления. Процесс 1500 может быть реализован отправителем HTTP-сообщения с запросом, таким как клиентский компьютер.

[0250] Как показано, закрытые данные или ключ A 1502 (например, PAN-информация) и закрытые данные или ключ B 1504 (например, хеш маркера доступа) могут зашифровываться службой или модулем 1506 шифрования для генерирования зашифрованных данных, содержащих зашифрованные данные A 1510 и связанную с ними метку 1512 аутентификации (например, КАС), зашифрованные данные B 1514 и связанную с ними метку 1516 аутентификации (например, КАС), и данные 1508 заголовка, которые могут содержать информацию о согласовании ключей и/или информацию о протоколе шифрования (например, набор шифров). В некоторых случаях данные для шифрования могут быть уже зашифрованы. Например, LUK может быть зашифрован посредством локального DES-ключа. В таких случаях служба 1506 шифрования может сначала расшифровывать локально зашифрованные данные (например, с помощью локального DES-ключа) перед их повторным шифрованием с помощью ключа защиты (например, на основе совместно используемого секретного ключа) для генерирования зашифрованных данных.

[0251] Службу или модуль 1506 шифрования предпочтительно эксплуатируют в относительно безопасной среде 1505. Безопасная среда может быть обеспечена аппаратным обеспечением, программным обеспечением или их комбинацией. Например, безопасная среда может быть обеспечена аппаратным модулем безопасности (HSM) и/или программным интерфейсом приложений (API). Операции приведенной в качестве примера службы или модуля шифрования обсуждаются по отношению к фиг. 19.

[0252] Упомянутые выше выдаваемые данные службы 1506 шифрования могут обрабатываться для генерирования HTTP-сообщения 1524 с запросом, которое форматируют согласно одному или более шаблонам, таким как один или более HTTP-шаблонов 1520 и/или один или более шаблонов 1522 содержимого JSON. В варианте осуществления выводимые данные службы 1506 шифрования, HTTP-шаблоны 1520, шаблоны 1522 содержимого JSON могут быть предоставлены в качестве входных данных для службы или модуля 1518 форматирования, который генерирует правильно форматированное HTTP-сообщение 1524 с запросом. В варианте осуществления HTTP-сообщение 1524 с запросом может быть форматировано согласно спецификации JWE.

[0253] HTTP-сообщение 1524 с запросом содержит HTTP-заголовок 1526 запроса, который содержит данные 1508 заголовка. Данные 1508 заголовка могут быть закодированы или искажены (например, с помощью кодирования Base64URL). Иллюстративные данные 1508 заголовка могут содержать ссылку открытого или закрытого ключа (например, порядковый номер сертификата), одноразовый открытый ключ, параметры согласования ключей, список КАС для полезных данных и глобальный КАС.

[0254] HTTP-сообщение 1524 с запросом также содержит зашифрованные данные A 1510 и зашифрованные данные B 1514 в HTTP-заголовке 1526 запроса или других подходящих частях сообщения с запросом. Например, в варианте осуществления HTTP-сообщение 1524 с запросом может содержать сериализованные в формате JWE данные A 1530 и сериализованные в формате JWE данные B 1532 в HTTP-заголовке запроса или другой части HTTP-запроса. Сериализованные в формате JWE данные могут представлять собой либо сериализованные в формате JWE JSON данные, либо сериализованные в формате JWE JSON данные. Все сериализованные в формате JWE данные могут содержать заголовок, зашифрованный текст и метку аутентификации, представленные в парах имя/значение. Данные могут быть закодированы в Base64URL перед включением в сериализованные в формате JWE данные. Заголовок сериализованных в формате JWE данных может содержать данные протокола, идентифицирующие алгоритм шифрования и ключ шифрования, используемые для шифрования конкретных данных. Например, заголовок для сериализованных в формате JWE данных A 1530 может содержать идентификатор алгоритма шифрования (например, «alg: alg_name») и ключа шифрования (например, «Kid: 1», относящийся к ключу шифрования SK₁), которые используются для шифрования данных A. Заголовок для сериализованных в формате JWE данных B 1532 может содержать идентификатор алгоритма шифрования (например, «alg: alg_name») и ключа шифрования (например, «Kid: 2», относящийся к ключу шифрования SK₂), которые используются для шифрования данных B. Зашифрованный текст для сериализованных в формате JWE данных A 1530 может содержать зашифрованные данные A 1510. Зашифрованный текст для сериализованных в формате JWE данных B 1532 может содержать зашифрованные данные B 1514. Метка аутентификации для сериализованных в формате JWE данных A 1530 может содержать метку 1512 аутентификации. Метка аутентификации для сериализованных в формате JWE данных B 1532 может содержать метку 1516 аутентификации.

[0255] На фиг. 16 показан приведенный в качестве примера процесс 1600 обработки HTTP-сообщения с запросом согласно некоторым вариантам осуществления. Процесс 1600 может быть реализован получателем HTTP-сообщения с запросом, таким как серверный компьютер.

[0256] Как показано, HTTP-сообщение 1524 с запросом, такое как приведенное на фиг. 15, может обрабатываться посредством модуля 1602 синтаксического анализа для извлечения данных 1508 заголовка, зашифрованных данных A 1510 и связанной с ними метки 1512 аутентификации, а также зашифрованных данных B 1514 и связанной с ними метки 1516 аутентификации. Модуль синтаксического анализа может выполнять декодирование Base64URL, если это необходимо.

[0257] Извлеченные данные могут подаваться в службу или модуль 1604 расшифровки для получения оригинальных закрытых данных, таких как закрытые данные A 1502 (например, PAN-информация в незашифрованном тексте) и закрытые данные B 1504 (например, хеш маркера доступа в незашифрованном тексте).

[0258] Служба или модуль 1604 расшифровки предпочтительно эксплуатируют в относительно безопасной среде 1605. Безопасная среда может быть обеспечена аппаратным обеспечением, программным обеспечением или их комбинацией. Например, безопасная среда может быть обеспечена HSM и/или API. Операции приведенной в качестве примера службы или модуля 1604 расшифровки обсуждаются со ссылкой на фиг. 20.

[0259] На фиг. 17 показан приведенный в качестве примера процесс 1700 генерирования HTTP-сообщения с ответом согласно некоторым вариантам осуществления. Процесс 1700 может быть реализован отправителем HTTP-сообщения с ответом, таким как серверный компьютер. Аспекты процесса 1700 могут быть подобны аспектам процесса 1500 шифрования данных для HTTP-сообщения с запросом, представленного на фиг. 15.

[0260] В процессе, подобном шифрованию данных A и данных B в процессе 1500, закрытые или ключевые данные C 1702 (например, ключ ограниченного использования (LUK)) и закрытые данные или ключ D 1704 (например, параметры маркеров) могут зашифровываться службой или модулем 1706 шифрования для генерирования зашифрованных данных, содержащих зашифрованные закрытые данные C 1710 и связанную с ними метку 1712 аутентификации (например, КАС), зашифрованные закрытые данные D 1714 и связанную с ними метку 1716 аутентификации (например, КАС), и данные 1708 заголовка, которые могут содержать информацию о согласовании ключей и/или информацию о шифровании (например, набор шифров). В некоторых случаях данные для шифрования могут быть уже зашифрованы. Например, LUK может быть зашифрован посредством локального DES-ключа. В таких случаях служба 1706 шифрования может сначала расшифровывать локально зашифрованные данные (например, с помощью локального DES-ключа) перед их повторным шифрованием с помощью ключа защиты (например, на основе совместно используемого секретного ключа) для генерирования зашифрованных данных.

[0261] Службу или модуль 1706 шифрования предпочтительно эксплуатируют в относительно безопасной среде 1705. Безопасная среда может быть обеспечена аппаратным обеспечением, программным обеспечением или их комбинацией. Например, безопасная среда может быть обеспечена HSM и/или API. Операции приведенной в качестве примера службы или модуля шифрования обсуждаются по отношению к фиг. 19. В некоторых вариантах осуществления модуль 1706 шифрования и модуль 1606 расшифровки, приведенный на фиг. 16, могут быть реализованы одним и тем же модулем или разными модулями.

[0262] Упомянутые выше выдаваемые данные службы 1706 шифрования могут обрабатываться для генерирования HTTP-сообщения 1724 с ответом, который форматируется согласно одному или более шаблонам, таким как один или более HTTP-шаблонов 1720 и/или один или более шаблонов 1722 содержимого JSON. Как проиллюстрировано, в варианте осуществления выводимые данные службы 1706 шифрования, HTTP-шаблоны 1720, шаблоны 1722 содержимого JSON могут быть предоставлены в качестве входных данных для службы или модуля 1718 форматирования, который генерирует правильно форматированное HTTP-сообщение 1724 с ответом. В варианте осуществления HTTP-сообщение 1724 с ответом может быть форматировано согласно спецификации JWE.

[0263] HTTP-сообщение 1724 с ответом содержит HTTP-заголовок 1726 ответа, который содержит данные 1708 заголовка. Данные 1708 заголовка могут быть закодированы или искажены (например, с помощью кодирования Base64URL). Иллюстративные данные 1708 заголовка могут содержать ссылку открытого или закрытого ключа (например, порядковый номер сертификата), одноразовый открытый ключ, параметры согласования ключей, список КАС для полезных данных и глобальный КАС.

[0264] HTTP-сообщение 1724 с ответом также содержит зашифрованные данные C 1710 и зашифрованные данные D 1714 в HTTP-заголовке 1726 ответа или других подходящих частях сообщения с ответом. Например, в варианте осуществления HTTP-сообщение 1724 с ответом может содержать сериализованные в формате JWE данные C 1730 и сериализованные в формате JWE данные D 1732 в HTTP-заголовке ответа или другой части HTTP-ответа. Сериализованные в формате JWE данные могут представлять собой либо сериализованные в формате JWE JSON данные, либо сериализованные в формате JWE JSON данные. Все сериализованные в формате JWE данные могут содержать заголовок, зашифрованный текст и метку аутентификации, представленные в парах имя/значение. Данные могут быть закодированы в Base64URL перед включением в сериализованные в формате JWE данные. Заголовок сериализованных в формате JWE данных может содержать данные протокола, идентифицирующие алгоритм шифрования и ключ шифрования, используемые для шифрования конкретных данных. Например, заголовок для сериализованных в формате JWE данных C 1730 может содержать идентификатор алгоритма шифрования (например, «alg: alg_name») и ключа шифрования (например, «Kid: 1», относящийся к ключу шифрования SK₁), которые используются для шифрования данных C. Заголовок для сериализованных в формате JWE данных D 1732 может содержать идентификатор алгоритма шифрования (например, «alg: alg_name») и ключа шифрования (например, «Kid: 2», относящийся к ключу шифрования SK₂), которые используются для шифрования данных D. Зашифрованный текст для сериализованных в формате JWE данных C 1730 может содержать зашифрованные данные C 1710. Зашифрованный текст для сериализованных в формате JWE данных D 1732 может содержать зашифрованные данные D 1714. Метка аутентификации для сериализованных в формате JWE данных C 1730 может содержать метку 1712 аутентификации. Метка аутентификации для сериализованных в формате JWE данных D 1732 может содержать метку 1716 аутентификации.

[0265] На фиг. 18 показан приведенный в качестве примера процесс 1800 обработки HTTP-сообщения с ответом согласно некоторым вариантам осуществления. Процесс 1800 может быть реализован получателем HTTP-сообщения с ответом, таким как клиентский компьютер. Аспекты процесса 1800 могут быть подобны аспектам процесса 1600 расшифровки данных из HTTP-сообщения с запросом, представленного на фиг. 16.

[0266] Как показано, HTTP-сообщение 1724 с ответом, такое как приведенное на фиг. 17, может обрабатываться посредством модуля 1802 синтаксического анализа для извлечения данных 1708 заголовка, зашифрованных данных C 1710 и связанной с ними метки 1712 аутентификации, и зашифрованных данных D 1714 и связанной с ними метки 1716 аутентификации.

[0267] Извлеченные данные могут подаваться в службу или модуль 1804 расшифровки для получения оригинальных закрытых данных, таких как закрытые данные C 1702 (например, PAN-информация в незашифрованном тексте) и закрытые данные D 1704 (например, хеш маркера доступа в незашифрованном тексте).

[0268] Служба или модуль 1804 расшифровки предпочтительно эксплуатируют в относительно безопасной среде 1805. Безопасная среда может быть обеспечена аппаратным обеспечением, программным обеспечением или их комбинацией. Например, безопасная среда может быть обеспечена HSM и/или API. Операции приведенной в качестве примера службы или модуля расшифровки обсуждаются по отношению к фиг. 20.

[0269] На фиг. 19 показан приведенный в качестве примера процесс 1900 шифрования для шифрования закрытых данных согласно некоторым вариантам осуществления. Процесс 1900 шифрования может использоваться для шифрования закрытых данных для включения в сообщение с запросом или сообщение с ответом. В некоторых вариантах осуществления процесс 1900 шифрования может осуществляться посредством службы или модуля шифрования, таких как описаны выше по отношению к фиг. 15 и 17. Обычно процесс 1900 шифрования может использоваться для генерирования зашифрованных данных для сохранения, передачи и для любых других подходящих целей.

[0270] На этапе 1 данные 1902 протокола согласования ключей используются для определения одного или более ключей 1904 сеанса (например, SK₀, SK₁ и SK₂). Данные протокола согласования ключей могут содержать открытые ключи, политики и тому подобное. Могут использоваться любые подходящие алгоритмы согласования ключей, например, ECDH и/или KDF.

[0271] На этапе 2 может генерироваться зашифрованный текст для одного или более элементов закрытых полезных данных. Закрытые данные X 1906 могут зашифровываться с помощью ключа сеанса (например, SK₁) и любого подходящего алгоритма шифрования (например, AEAD) для генерирования зашифрованных данных X (например, зашифрованного текста 1908 данных A) и связанного кода аутентификации сообщений (например, КАС 1910 данных X). Подобным образом, закрытые данные Y 1912 могут зашифровываться с помощью ключа сеанса (например, SK₂) и любого подходящего алгоритма шифрования (например, AEAD) для генерирования зашифрованных данных Y (например, зашифрованного текста 1914 данных Y) и связанного кода аутентификации сообщений (например, КАС 1916 данных Y). В некоторых примерах данные X и данные Y могут соответствовать данным A и данным B, обсуждаемым по отношению к фиг. 15–16, или данным C и данным D, обсуждаемым по отношению к фиг. 17–18.

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

[0273] В варианте осуществления элементы зашифрованных данных и их КАС могут быть преобразованы посредством кодирования Base64 для включения в компактный сериализованный формат JWE. Элементы сериализированных зашифрованных данных могут быть включены в HTTP-сообщение. Примеры таких компактных элементов сериализованных в формат JWE зашифрованных данных включают сериализованные в формат JWE данные A 1530 и сериализованные в формат JWE данные B 1532, представленные на фиг. 15, а также сериализованные в формат JWE данные C 1730 и сериализованные в формат JWE данные C 1732, представленные на фиг. 17.

[0274] На этапе 3 генерируются данные 1940 заголовка. Обычный текст 1936 и текст 1938 для шифрования могут быть зашифрованы с помощью ключа сеанса (например, SK₀) и любого подходящего алгоритма шифрования (например, AEAD) для генерирования данных 1940 заголовка, содержащих данные 1918 протокола в виде обычного текста, зашифрованный текст (например, зашифрованные данные 1932 протокола) и глобальный КАС 1934. Обычный текст 1936 может содержать данные 1918 протокола в виде обычного текста. Данные 1918 протокола в виде обычного текста могут содержать данные 1902 протокола согласования ключей, обсуждаемые выше, такие как информация об открытых ключах (например, защищенный идентификатор ключа, одноразовые открытые ключи). После применения алгоритма шифрования данные 1918 протокола в виде обычного текста не зашифрованы, но целостность защищена посредством глобального КАС.

[0275] Текст 1938 для шифрования может содержать защищенные данные 1920 протокола и данные протокола, характерные для элемента, для каждого зашифрованного элемента полезных данных. Защищенные данные 1920 протокола могут содержать искаженные или заблокированные открытые ключи, политики, информацию о наборе шифров и тому подобное. Данные протокола, характерные для элемента, могут содержать дескриптор данных (например, дескриптор 1922 данных X или дескриптор 1926 данных Y) и КАС данного элемента полезных данных (например, КАС 1924 данных X или дескриптор 1928 данных Y). Например, дескриптор 1922 данных X может содержать комбинацию из (например, объединение) метки, идентифицирующей данные X (метка X), идентификатора ключа шифрования и длины КАС данных X. Дескриптор 1926 данных Y может содержать комбинацию (например, объединение) из метки, идентифицирующей данные Y (метка Y), идентификатора ключа шифрования и длины КАС данных Y.

[0276] В варианте осуществления данные 1940 заголовка, сгенерированные на этапе 3, могут быть включены в часть заголовка HTTP-сообщения, такую как показана посредством данных 1508 заголовка на фиг. 15, и данных 1708 заголовка, представленных на фиг. 17.

[0277] На фиг. 20 показан приведенный в качестве примера процесс 2000 расшифровки данных согласно некоторым вариантам осуществления. Процесс 2000 расшифровки может использоваться для расшифровки данных, включенных в сообщение с запросом или сообщение с ответом. Данные могли быть зашифрованы согласно такому процессу шифрования, как описан по отношению к фиг. 19. В некоторых вариантах осуществления процесс 2000 расшифровки может осуществляться посредством службы или модуля расшифровки, таких как описаны выше по отношению к фиг. 16 и 18. Обычно процесс 2000 расшифровки может использоваться для расшифровки зашифрованных данных, извлеченных из хранилища, при передаче, для любых других подходящих целей.

[0278] На этапе 1 некоторые или все данные 2002 заголовка могут использоваться для определения одного или более ключей 2010 сеанса (например, SK₀, SK₁ и SK₂). Ключи 2010 сеанса могут быть такими же как те, что определены в процессе шифрования, как описано в отношении фиг. 19. Данные 2002 заголовка могут быть подобны данным 1940 заголовка, описанным в отношении фиг. 19. Например, данные 2002 заголовка могут содержать данные 2004 протокола в виде обычного текста, зашифрованные данные 2006 протокола и глобальный КАС 2008. В некоторых вариантах осуществления только данные 2004 протокола в виде обычного текста данных 2002 заголовка используются для формирования ключей сеанса 2010. Данные 2004 протокола в виде обычного текста могут содержать информацию о согласовании ключей для формирования ключей, таких как открытые ключи, политиках и тому подобном. Любые подходящие алгоритмы согласования ключей (например, ECDH, KDF) могут использоваться для формирования ключей сеанса.

[0279] На этапе 2 данные протокола, включенные в данные 2002 заголовка, могут быть расшифрованы и аутентифицированы с помощью ключа сеанса (например, SK₀) и подходящего алгоритма расшифровки (например, AEAD). Данные 2004 протокола в виде обычного текста могут аутентифицироваться с помощью глобального КАС 2008. Зашифрованные данные 2006 протокола могут расшифровываться для получения защищенных данных 2012 протокола и данных протокола, характерных для элемента (например, дескриптора 2014 данных X, КАС 2016 данных X, дескриптора 2018 данных Y и КАС 2020 данных Y). Расшифрованные данные могут проверяться на подлинность (например, с помощью глобального КАС 2008).

[0280] На этапе 3 элементы зашифрованных полезных данных могут расшифровываться и аутентифицироваться. Элементы зашифрованных полезных данных могут быть получены из принятых объектов сериализации, таких как объекты сериализации в компактном формате JWE, включенные в HTTP-сообщения, такие как описаны в отношении фиг. 15–18. Например, зашифрованный текст 2022 данных X и КАС 2016 данных X могут быть предоставлены в качестве входящих данных для подходящего алгоритма расшифровки (например, AEAD) с помощью подходящего ключа расшифровки (например, SK₁) для получения оригинальных данных X 2014. Целостность данных X может проверяться на подлинность с помощью КАС 2016 данных X. Зашифрованный текст 2026 данных Y и КАС 2020 данных Y могут быть предоставлены в качестве входных данных для подходящего алгоритма расшифровки (например, AEAD) с помощью подходящего ключа расшифровки (например, SK₂) для получения оригинальных данных X 2028. Целостность данных Y может проверяться на подлинность с помощью КАС 2020 данных Y. В некоторых вариантах осуществления расшифровка элементов данных может выполняться на основе данных протокола (например, информации о наборе шифров, данных протокола, характерных для элемента), полученных из этапа 2. Элементы зашифрованных данных могут расшифровываться и/или аутентифицироваться по мере необходимости для снижения риска нежелательного раскрытия закрытой информации.

[0281] Несмотря на то, что на фиг. 19–20 изображены процесс 1900 шифрования и процесс 2000 расшифровки как два отдельных процесса, в некоторых вариантах осуществления оба из них могут осуществляться одним модулем или компьютером. В некоторых других вариантах осуществления процесс 1900 шифрования и процесс 2000 расшифровки могут осуществляться разными модулями или компьютерами.

[0282] В некоторых вариантах осуществления процесс 1900 шифрования и процесс 2000 расшифровки могут использоваться для шифрования и расшифровки любых подходящих типов данных, таких как документы и объекты данных. Например, процесс 1900 шифрования может использоваться для шифрования полей с закрытыми данными в конкретном документе для генерирования полей с зашифрованными данными, которые заменяют поля с закрытыми данными. Зашифрованные данные протокола, описывающие шифрование, могут также генерироваться и сохраняться с документом. Зашифрованный документ может сохраняться или передаваться. Субъект может принимать зашифрованный документ по каналу связи (например, через HTTP-сообщение) или иным образом стремиться осуществить доступ к зашифрованному документу из хранилища. Чтобы осуществить доступ к закрытым данным в документе, процесс 2000 расшифровки может использоваться для расшифровки зашифрованного документа и раскрытия одного или более полей с закрытыми данными.

IV. Конфиденциальное осуществление политик

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

[0284] На фиг. 21 показано дерево 2100 решений для обработки сообщения с запросом для осуществления серверных политик согласно некоторым вариантам осуществления. Дерево 2100 решений может использоваться серверным компьютером для обработки сообщения с запросом с клиентского компьютера.

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

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

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

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

V. ВЫЧИСЛИТЕЛЬНОЕ УСТРОЙСТВО

[0289] На фиг. 22 представлена блок-схема высокого уровня компьютерной системы, которая может быть использована для осуществления любого из элементов или компонентов, описанных выше. Подсистемы, представленные на фиг. 22, соединены посредством системной шины 2275. Дополнительные подсистемы включают принтер 2203, клавиатуру 2206, несъемный диск 2207 и монитор 2209, который подключен к адаптеру 2204 дисплея. Периферийные устройства и устройства ввода/вывода (I/O), которые соединяются с I/O контроллером 2200 ввода/вывода (I/O), могут быть соединены с компьютерной системой с помощью любого количества средств, известных в данной области техники, таких как последовательный порт. Например, последовательный порт 2205 или внешний интерфейс 2208 могут быть использованы для соединения вычислительного устройства с глобальной сетью, такой как Интернет, устройством ввода типа мышь или сканером. Соединение по системной шине 2275 позволяет центральному процессору 2202 осуществлять связь с каждой подсистемой и управлять выполнением команд из системной памяти 2201 или несъемного диска 2207, а также обмен информацией между подсистемами. Системная память 2201 и/или несъемный диск могут представлять собой машиночитаемый носитель.

[0290] Запоминающие носители и машиночитаемые носители для хранения кода или частей кода могут включать любые соответствующие носители, известные или используемые в данной области техники, включая запоминающие носители и средства связи, такие как, но без ограничения, энергозависимые и энергонезависимые, съемные и несъемные носители, реализованные любым способом или технологией для хранения и/или передачи информации, такой как машиночитаемые команды, структуры данных, программные модули или другие данные, включая ОЗУ, ПЗУ, ЭСППЗУ (электрически стираемое программируемое постоянное запоминающее устройство), флеш-память или другую запоминающую технологию, CD-ROM, цифровой универсальный диск (DVD) или другой оптический носитель, магнитные кассеты, магнитную ленту, запоминающее устройство на магнитных дисках или другие магнитные запоминающие устройства, сигналы данных, передачи данных или любые другие носители, которые могут быть использованы для хранения или передачи желаемой информации и к которым может осуществить доступ компьютер. На основании описания и указаний, представленных в данном документе, для специалиста в данной области техники будут очевидны другие пути и/или способы для осуществления разных вариантов осуществления.

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

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

[0293] Любые из программных компонентов или функций, описанных в данной заявке, могут быть реализованы в виде программного кода, который должен быть исполнен процессором, с использованием любого подходящего компьютерного языка, такого как, например, Java, C++ или Perl, с использованием, например, традиционных или объектно-ориентированных подходов. Программный код может быть сохранен в виде последовательности инструкций или команд на машиночитаемом носителе, таком как оперативное запоминающее устройство (ОЗУ), постоянное запоминающее устройство (ПЗУ), магнитный носитель, например, жесткий диск или гибкий диск, или оптический носитель, например, CD-ROM. Любой такой машиночитаемый носитель может находиться на или в одном вычислительном устройстве и может присутствовать на или в разных вычислительных устройствах в пределах системы или сети.

[0294] Один или более признаков из любого варианта осуществления можно сочетать с одним или более признаками любого другого варианта осуществления без отхода от объема настоящего изобретения.

[0295] Формы единственного числа обозначают «один или более», если иное не указано отдельно.