СПОСОБ И УСТРОЙСТВО ФОРМИРОВАНИЯ ЗАЩИЩАЮЩИХ ДАННЫХ И ПРОДУКТ КОМПЬЮТЕРНОЙ ПРОГРАММЫ Российский патент 2013 года по МПК H04L9/32 H04L29/06 

Область изобретения

Настоящее изобретение относится к области управления обменом данных между двумя объектами в сети связи.

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

Известные технические решения проблемы

Известный уровень техники

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

Следовательно, чтобы установить такой сеанс связи, два объекта используют механизмы, которые, как предполагается, гарантируют, что созданный сеанс связи не может быть взломан или прослежен. Ниже будет описана работа по протоколам TLS и SSL. Хотя это описание более подробно освещает протокол TLS, оно также относится и к протоколу SSL.

Протокол TLS организован на базе пяти объектов программного обеспечения, которые работают совместно: APPLICATION (приложение), HANDSHAKE (установление соединения), CCS (унифицированный набор команд), ALERT (предупреждение) и RECORD (запись). Объект «APPLICATION» относится к программному обеспечению, которое будет выполнять безопасный сеанс связи (слой 7 модели OSI). Объекты "HANDSHAKE", "CCS", "ПРЕДУПРЕЖДЕНИЕ" и "RECORD" (также называемые слоями) являются объектами, которые используются как часть приложения протокола TLS, и их подробное описание может быть найдено в ссылке "RFC 2246", изданной комитетом IETF (Рабочая группа по инженерным проблемам Интернета). Такое приложение протокола TLS выполнено на уровне 5 модели OSI.

Архитектура стека OSI может быть описана следующим образом: слой, управляемый объектом "RECORD" (также называемый слоем "RECORD" (запись)) передает сообщения, созданные объектами «APPLICATION», "HANDSHAKE", «CCS», и "ALERT" посредством заголовка из 5 восьмибитовых байтов, который определяет объект, создающий сообщение, версию используемого протокола TLS и длину сообщения. Само сообщение также содержит заголовок, который указывает на тип сообщения и длину соответствующих данных. Однако структура сообщений «APPLICATION» не определяется стандартом TLS. Действительно, каждое приложение включает обмен сообщениями, структура которых определена протоколом приложения, например HTTPS (гипертекстовый транспортный протокол).

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

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

Объект слоя "HANDSHAKE" (также называемый слоем "HANDSHAKE") выполняет аутентификацию и процедуры вычисления ключей. Есть два способа аутентификации: полный способ (называемый "Full Session" (Полный Сеанс) и быстрый способ ("Session Resumption" (Возобновление сеанса)). Эти два способа будут описаны позже более подробно.

Слой "HANDSHAKE" обеспечивает алгоритмы кодирования и целостности, используемых объектом слоя «RECORD», которые идентифицированы списком криптографических опций, называемым "cipher_suite".

В конце успешной процедуры аутентификации уровень записей определяет величину, называемую master_secret. Используя два случайных числа, созданные клиентским объектом (client_random) и объектом сервера (server_random), он вычисляет ряд ключей (keys_bloc), используемых для кодирования и проверки целостности полученных и отправленных данных:

keys_block=PRF (master_secret, "key expansion", server_random client_random);

PRF (Pseudo_Random_Function) является функцией, которая генерирует псевдослучайные данные; символ "I" указывает на операцию конкатенации.

В упрощенном виде параметр keys_bloc - объединение двух пар ключей (KcRx, KiRx) и (KcTx, KiTx), используемых соответственно для кодирования (префикс Kc) и целостности (префикс Ki) полученных данных (суффикс Rx) и переданных данных (суффикс Tx).

Слой «CCS» "унифицированный набор команд" сигнализирует об изменениях параметров безопасности в объекте "RECORD". Он активизирует начало кодирования и процедуру проверки подлинности данных, используя параметры "keys_bloc" и "cipher_suite".

Объект слоя ALERT (также называемый слоем ALERT) сигнализирует об ошибках, обнаруженных объектом "HANDSHAKE" (в случае сбоя фазы аутентификации) или слоем «RECORD» (обнаружение ошибки при проверке подлинности или конец сеанса связи).

Слой «RECORD» выполняет четыре типа операций:

- фрагментацию данных в блоки, максимальный размер которых 2¹⁴ (16 384) восьмибитовых байтов;

- оптимальное сжатие данных; эта операция, как правило, не выполняется;

- генерацию подписей (основанную на алгоритме НМАС, определенном RFC 2104 (набор протоколов));

- кодирование данных.

Набор параметров, требуемых для операции слоя «RECORD», называется "security_parameters" (параметры безопасности) и дополнительно содержат величины "keys_bloc", произведенные объектом HANDSHAKE.

Сообщения, передаваемые между слоем приложения и слоем TCP, кодируются и декодируются слоем «RECORD», используя набор двух пар ключей (KcRx, KiRx) и (KcTx, KiTx), описанный выше.

- Сообщения, полученные слоем «RECORD», кодируются ключом KcRx ({M} KcRx) и выданной подписью HMAC (KiRx, M), связанной с ключом KiRx. Последний проверяет подпись HMAC и передает декодированную величину слою приложения.

- Сообщения, переданные слоем приложения, кодируются слоем «RECORD», используя ключ KcTx ({M.} KcTx) и выданную подпись НМАС (M, KiTx), связанную с ключом KiTX.

Когда режим кодирования активизирован, слой RECORD работает следующим образом: "MESSAGE" (сообщение), переданное/полученное объектом, таким как "HANDSHAKE" или «APPLICATION», имеет заголовок, содержащий три параметра: тип, версия, длина. Полное сообщение "MESSAGE", "HMAC signature" (подпись HMAC) и "padding octets" (заполнение восьмибитовых байтов) кодируются, используя алгоритм, о котором договариваются во время аутентификации и выдачи ключа.

Подпись "HMAC" вычисляется из заголовка, "MESSAGE" и номера блока (seq_num) (инициированный по величине 0 и увеличенный каждый раз, когда используется слой «RECORD») по следующим отношениям:

HMAC (Ki, seq_num Тип Длина версии MESSAGE).

Как упомянуто выше, используются два режима открытия сеанса связи TLS, называемого "Full Session" (Полный сеанс связи) и "Session Resumption" (Возобновление сеанса связи).

Следовательно, например, в случае, когда установлен "Полный сеанс связи", используя алгоритм RSA с взаимной аутентификацией ("Client Authentification Handshake"), между клиентским объектом и объектом сервера, клиентский объект начинает сеанс с сообщения "Client_Hello". Объект сервера отвечает набором сообщений "Server_Hello", "Certificate", «Certificate_Request" (запрос на сертификацию) Server_Hello_Done" (запрос на сертификацию выполнен). Затем клиентский объект посылает сообщения "Certificate", "Certificate_Verify" (проверка сертификации), "Client_Key_Exchange" (обмен ключами), "Change_Cipher_Spec" (изменить код) и "Finished".

В этой процедуре клиентский объект проверяет сертификат аутентификации сервера, извлекая его открытый ключ RSA, затем посылает ему кодированную величину, называемую "pre_master_secret" этого ключа. Ключ "master_secret" вычисляется из элементов "Client-random", "Server-random" и "pre-master-secret". Сообщение "Certificate_Verify" содержит подпись, сделанную, используя частный ключ RSA клиента, который удостоверяет идентичность последнего (его сертификат в сообщении "Certificate").

В конце этой процедуры аутентификации клиентский объект и объект сервера получают новую величину алгоритма "master_secret", из которой выведены ключи "keys_bloc". Параметр "Session_ID", посланный в рамках сообщения "Server_Hello", обеспечивает индекс "master_secret". Затем данные, созданные слоем «APPLICATION», транспортируются объектом "RECORD", который гарантирует конфиденциальность и достоверность через ключи Kc и Ki.

Когда сеанс "Session Resumption" открыт, на предыдущей стадии "Full Session" уже вычислен "master_secret", идентифицированный индексом "SessionID", который будет получен клиентом. Фаза аутентификации упрощена и состоит для этих двух частей (клиентский объект и объект сервера), доказывающих их знание величины "master_secret". Клиентский объект открывает сеанс связи TLS сообщением "Client_Hello", содержащим индекс ("SessionID") предыдущего сеанса связи. Объект сервера отвечает рядом сообщений "Server_Hello", "Change_Cipher_Spec" и "Finished". Это указывает на возобновление сеанса связи, вставляя величину "SessionID" в сообщение "Server_Hello", которое идентично содержанию сообщения "Client_Hello". Затем клиентский объект выдает сообщения "Change_Cipher_Spec" и "Завершение сеанса".

Алгоритм "master_secret" повторно не вычисляется, однако получен новый набор "keys_bloc" из "master_secret", "ClientRandom" и элементов "ServerRandom", используя следующую функцию:

Keys_block=PRF (master_secret, "key_expansion", server_random client_random).

Затем данные, сгенерированные слоем «APPLICATION», транспортируются объектом "RECORD", который гарантирует конфиденциальность и достоверность посредством ключей Kc и Ki.

Механизм "Session Resumption" (Возобновление сеанса связи) упрощает обмен информацией в сеансе связи TLS. Первый механизм "Full Session" выполняет единичную или взаимную аутентификацию двух концов (клиент и сервер) и создает "master_secret". Следующие сеансы связи, основанные на механизме "Session Resumption" снова используют "master__secret", чтобы вычислить новые ключи для кодирования и целостности сообщения.

Недостатки известного уровня техники

Описав механизмы установки сеанса связи TLS, выделим две стадии безопасного обмена информацией:

- стадию аутентификации, позволяющую получить master_secret и вычислить ключи сеанса связи (keys_bloc), и

- стадию передачи информации, защищенной слоем «RECORD» в кодированном виде.

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

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

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

Принимая во внимание, что многие приложения, например виртуальные сети (VPN), основанные на SSL/TLS, вычислительные сети или оверлейные сети нуждаются в определенных гарантиях безопасности, чтобы предотвратить неправомерный захват идентичности, иными словами, несанкционированное использование сервиса компьютерными хакерами.

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

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

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

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

- стадию установки третьего защищенного объекта, связанного с указанным первым объектом;

- стадию формирования, по меньшей мере, части указанных защищающих данных указанного третьего объекта;

- стадию передачи указанных защищающих данных от указанного третьего защищенного объекта указанному первому объекту.

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

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

Согласно одному оригинальному примеру воплощения изобретения, указанный третий объект представляет собой микросхему типа "JavaCard".

Таким образом, изобретение предлагает устройство, которое осуществляет протокол безопасности, который не будет связан с устройством, обеспечивающим связь. Кроме того, использование микросхемы типа "JavaCard" гарантирует, что этот объект, ответственный за осуществление протокола безопасности, недоступен и полностью безопасен. Таким образом, дополнительный уровень безопасности, обеспечиваемый изобретателями, добавляется к остальной части протокола безопасности.

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

Следовательно, изобретение устанавливает защищенный сеанс связи на основе протокола SSL, который является одним из главных протоколов в этой области.

Согласно одному конкретному признаку изобретения, указанный протокол для обеспечения безопасных сеансов связи является протоколом TLS.

Следовательно, изобретение устанавливает защищенный сеанс связи, на основе протокола TLS, который является одним из обычно используемых протоколов в этой области.

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

- стадию передачи указанным первым объектом, по меньшей мере, одного сообщения, предназначенного для слоя «RECORD», используемого в указанном третьем объекте;

- стадию получения, указанным первым объектом, по меньшей мере, одного сообщения от указанного слоя «RECORD»;

- стадию вычисления ряда ключей указанным третьим объектом;

- стадию сбора указанного набора ключей, доступных указанному первому объекту от указанного третьего объекта;

- стадию восстановления защищенного идентификатора сеанса связи.

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

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

- средство установки, приданное указанному первому объекту;

- средство формирования, по меньшей мере, части указанных данных защиты;

- средство передачи указанных данных защиты указанному первому объекту.

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

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

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

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

ПЕРЕЧЕНЬ ЧЕРТЕЖЕЙ

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

- фигура 1 - блок-схема способа формирования защищенных данных согласно изобретению;

- фигура 2 - пример осуществления способа формирования данных в модуле безопасности согласно изобретению;

- фигура 3 иллюстрирует средство осуществления способа формирования двумя объектами, используя два модуля безопасности в способе "полного сеанса связи";

- фигура 4 иллюстрирует средство осуществления способа формирования двумя объектами, используя два модуля безопасности в режиме "Session Resumption";

фигура 5 также иллюстрирует средство осуществления способа формирования двумя объектами, используя два модуля безопасности в режиме "Session Resumption";

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

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

Описание принципа изобретения

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

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

Такая информация, например, может быть сеансовыми ключами (keys_bloc) или "master_secret" (в соответствии с уровнем требуемой безопасности) для программы, которая требует защищенного обмена информацией в соответствии с протоколами SSL/TLS.

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

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

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

На фигуре 1 представлен способ формирования защищенных данных согласно изобретению, содержащий:

- стадию установки (100) модуля безопасности (например, микросхемы), приложенного к первому объекту (например, персональному компьютеру);

- стадию формирования (101) части защищенных данных в модуле безопасности;

- стадию передачи (102) защищенных данных от модуля безопасности первому объекту.

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

Описание примера осуществления

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

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

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

Однако многие приложения, например виртуальные сети (VPN), основанные на протоколе SSL/TLS, вычислительных сетях или "оверлейных" сетях, нуждаются в определенных гарантиях безопасности, чтобы предотвратить неправомерный захват идентичности, которая будет использована хакерами. Сложные операционные системы компьютеров сегодня разрешают выполнение злонамеренных программ, таких как троянские кони, черви и вирусы, способные собирать идентификацию и ключи RSA пользователей.

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

Модуль безопасности, осуществляющий способ согласно изобретению, выполняет функции клиента или объекта сервера TLS. Следовательно, в этом конкретном примере осуществления, способ согласно изобретению выполняет вышеописанные операции «HANDSHAKE», «ALERT», «CCS» и «RECORD» по каналу общего пользования.

На фигуре 2 представлен модуль безопасности (210), в котором используется протокол TLS согласно способу формирования изобретения и объекту пользователя (200), который представляет собой приложение (2000), содержащее поднабор стека TLS, который обязательно является слоями «RECORD» (2004), "ALERT" (2002) и произвольно CCS (унифицированный набор команд) (2003), а также "HANDSHAKE" (2001). Слой «RECORD» (2004) имеет интерфейс связи со слоем "TCP" (2005).

В этом примере осуществления такой модуль безопасности предлагает функциональный интерфейс (220), который содержит восемь команд: "SET-credentials" (ввод удостоверяющих данных, "Start" (Пуск), "Process-TLS", "GET-Keys_bloc" (установить блок ключей), "Compute-Keys_bloc" (вычислить блок ключей), "GET-Cipher_suite" (получить величину Cipher_suite, "GET-SessionID (получить идентификатор), "GET-Master_secret" (получить ключ Master_secret). Такие команды могут быть выполнены, используя стандарт ISO 7816 по кодировке, обычно называемой "APDU" (протокольный блок данных приложения), ("PDU" (протокольный блок данных) седьмого слоя (Приложение) модели "OSI").

Модуль безопасности (210), который осуществляет способ формирования согласно изобретению, содержит объекты, требуемые для реализации способа защиты, т.е. слои "RECORD" (2104) и "ALERT" (2102) и произвольно слои "CCS" (2103) и "HANDSHAKE" (2101).

Функциональный интерфейс (220) позволяет пользовательскому объекту (200) вызвать модуль безопасности (210) для формирования данных защиты.

Описание команд

Команда SET-Credentials

Роль модуля, который отражает поведение клиента или режим объекта сервера так же как различные параметры, требуемые для его работы, обычно ассоциируется с сертификатами «аккредитива» или "именем и паролем пользователя " (X509, частный ключ доступа RSA), который активизируется командой SET-Credentials (установить верительные данные).

START (Unix-Time)

В этом примере осуществления, команда "Пуск" устанавливает сеанс связи TLS; поскольку модули безопасности не имеют счетчика времени, эта команда также обеспечивает время по Гринвичу в формате UNIX, который является числом в 32 бита, которым измеряют количество секунд, которые прошли с 1 января 1970 года.

Процесс TLS

Пакеты TLS, которые фактически являются сообщениями, созданными объектом RECORD, передаются в модуль безопасности, используя команду Process_TLS (запись пакетов), которая возвращает одно или несколько записанных сообщений.

RECORD-Packets=Process-TLS (RECORD-Packets)

GET-Kevs_bloc

Когда модуль безопасности TLS успешно выполнил аутентификацию своего корреспондента, он вычисляет keys_bloc, слой RECORD переключается в режим кодирования и передает сообщения CCS FINISHED (завершение сеанса). Команда GET-Keys_bloc затем собирает все доступные ключи keys_bloc=GET-Keys_bloc.

Пользователь службы модуля безопасности может затем управлять автономно (без модуля безопасности) своим собственным слоем RECORD. Действительно, поскольку он знает ключи защищенного канала (keys_bloc), и текущая величина параметра seq_num равна 1 (величина 0 используется для вычисления достоверности НМАС завершенного сообщения).

Compute-Keys_bloc

Команда вычисления Keys_bloc, связанного со случайными числами, сгенерированными объектом клиента и объектом сервера (Client-Random и Server-Random) позволяет вычислить параметр "keys_bloc". Это полезно в сеансе связи типа «Session Resumption» (возобновление сеанса), где пользователь модуля безопасности использует только этот модуль, чтобы получить keys_bloc.

keys_bloc=Compure-Keys_bioc (Client-Random, Server-Random)

Важно отметить, что в этом случае модуль безопасности не экспортирует величину "master_secret". Поэтому невозможно выполнить сеанс связи типа «возобновление сеанса» при отсутствии модуля безопасности, который, таким образом, гарантирует добросовестность пользователя по отношению к серверу.

GET-Cipher_suite

Команда GET-CIPHER_SUITE позволяет идентифицировать параметры безопасности, которые индексированы числом cipher_suite, связанным с объектом RECORD.

cipher_suite=GET-Cipher_suite

GET-SessionID

Команда GET-SessionID возвращает параметр "SessionID", связанный с текущим сеансом связи, на предыдущий сеанс связи. Это полезная информация для пользователя, который желает частично управлять сеансом "Session Resumption".

SessionID=GET-SessionID ()

GET-MASTER_SECRET

Команда GET-Mastert_secret собирает "master_secret", связанный с "SessionID" текущего или предыдущего сеанса связи. Это дополнительная команда и она служит для управления сеансом "Session Resumption", для которого пользователь не использует службу вычисления "keys_bloc".

master_secret=GET-Master_secret

Выполнение протокола

Используя восемь команд, описанных выше, можно осуществить, по меньшей мере, три основных способа использования модуля безопасности TLS.

Первый способ показан на фигуре 3. Здесь показано, что выполнение способа согласно изобретению относится к открытию сеанса связи способом "полного сеанса связи", используя алгоритм RSA, со взаимной аутентификацией ("Client Autentification Handshake"). Клиентский объект (350) устанавливает это с помощью сообщения Client_Hello (301). Объект сервера (360) отвечает рядом сообщений Server_Hello (302), Certificate (303), CertificateRequest (304) и ServerHelloDone (305). Клиентский объект затем выдает сообщения Certificate (306), CertificateVerify (307), ClientKeyExchange (308), ChangeCipherSpec (309) и Finished (310).

В этой процедуре клиентский объект проверяет достоверность сертификата сервера, извлекает его открытый ключ доступа RSA и затем посылает серверу кодированную величину этого ключа, называемую pre_master_secret. Величины master_secret вычисляется из элементов Client-Random, Server-Random и pre_master_secret. Сообщение CertificateVerify (307)содержит подпись, сделанную с частным ключом доступа клиента RSA, который удостоверяет личность последнего (его сертификат присутствует в сообщении Certificate).

В конце процедуры аутентификации клиентский объект и объект сервера получает новую величину master_secret, из которой выводятся ключи keys_bloc. Параметр SessionID, посланный в сообщении Server_Hello, обеспечивает индекс master_secret. Затем данные, сформированные слоем приложения, транспортируются объектом RECORD (313), который гарантирует конфиденциальность и достоверность с помощью ключей Kc и Ki.

Описанные выше стадии, выполняются в модулях безопасности: один для клиентского объекта (35) и один для объекта сервера (36). Следовательно, как показано на фигуре 3, стадии, описанные выше, не осуществляются в объектах клиента (350) и сервера (360), но только проходят через эти объекты. Эффективное выполнение этих стадий осуществляется в модулях безопасности, используя команды функционального интерфейса модуля.

В каждом из двух модулей безопасности используются четыре команды: "Start" (3001, 3002) для установки сеанса связи TLS, "Process-TLS" обрабатывает пакеты TLS (не показано), "GET_keys_bloc" (3003, 3004) собирает ключи слоя RECORD, и "GET_Cipher_suite" (3005, 3006) указывает на список кодированных алгоритмов, используемых для управления безопасным каналом. Клиентский объект открывает сеанс связи TLS с объектом сервера, как правило, через порт TCP 443. На этой фигуре модуль безопасности установлен на стороне клиентского объекта (350) и на стороне объекта сервера (360).

Второй способ показан на фигуре 4. В этом случае предыдущий связи типа "Full Session" (полный сеанс) позволяет получить ключ "master_secret", идентифицированный индексом "SessionID". Фаза аутентификации упрощена и состоит для этих двух частей (клиентский объект и сервер) доказательства их знания величины master_secret. Клиентский объект (440) открывает сеанс связи TLS сообщением Client_Hello (401), содержащим индекс (SessionID) предыдущего сеанса связи. Объект сервера (460) отвечает рядом сообщений "Server_Hello" (402), "ChangeCipherSpec" (403) и "Finished" (404). Это указывает на возобновление сеанса связи, вставляя величину "SessionID" в сообщение "Server_Hello", идентичному содержащемуся в сообщении "Client_Hello". Клиентский объект затем посылает сообщения "ChangeCipherSpec" (405) и "Finished" (406).

Ключ "master_secret" повторно не вычисляется, однако новый набор "keys_bloc" извлекается из элементов "master_secret", "ClientRandom" и "ServerRandom".

Keys_block=PRF (master_secret, "key expansion", server_random client_random).

Затем данные, сформированные слоем APPLICATION, транспортируются объектом RECORD (407) (408), который гарантирует конфиденциальность и достоверность с помощью ключей Kc и Ki.

Механизм Session Resumption "Session Resumption" упрощает обмен информацией во время сеанса TLS. Первый Full Session "Full Session" делает одиночную или взаимную аутентификацию двух концов линии связи (клиентский объект и сервер) и выдает ключ master_secret. Следующие сеансы связи, основанные на механизме Session Resumption, снова используют master_secret, чтобы вычислить новое кодирование и ключи подлинности.

В этом примере проведения сеанса связи типа "Session Resumption" осуществляется связь между клиентским объектом и объектом сервера. Величина "master_secret" защищена модулем безопасности на клиентском объекте и/или на стороне сервера.

Требуются три команды: "Start" (4001, 4002) устанавливает модуль безопасности; "GET-SessionID" (4003, 4005) восстанавливает "SessionID" предыдущего сеанса связи, который может быть вставлен в сообщение "Client-Hello" (4001) или разрешить проверку наличия "master_secret" на стороне сервера (4003);

"Compute-Keys_bloc" вычисляет "keys_bloc", используя случайные числа, обмененные клиентским объектом (4004) и объектом сервера (4006).

Третий способ показан на фигуре 5. Сеанс связи типа «Session Resumption» устанавливается между объектами клиента (550) и сервера (560). Величина "master_secret" хранится модулем безопасности на стороне клиента (55) и/или сервера (56).

Требуются три команды: команда "Start" (5001, 5002) служит для установки модуля безопасности; команда "GET-SessionID" возвращает "SessionID" предыдущего сеанса связи, который может быть вставлен в сообщение "Client_Hello" (5003) или разрешает проверку наличия "master_secret" на стороне сервера (5005). Команда "GET-Master-secret" возвращает величину "master-secret" (5004, 5006). Этот режим работы совместим с программным обеспечением, таким как "OpenSSL", который использует объекты "SESSION", хранящиеся в файлах. В этом случае модуль безопасности играет роль сменной кэш-памяти величины "master_secret". Стадии 401-408 идентичны описанным со ссылкой на фигуру 4.

Описание модуля безопасности согласно изобретению

На фигуре 6 показан модуль безопасности в виде интегральной схемы (600), например, типа ST22, изготавливаемой компанией ST Microelectronics и доступной в различных форматах, таких как платы, поливиниловые карточки (микросхемы, СИМ-карты, флеш-карты, вставляемые в порт USB или ММС.

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

Более точно, эти средства включают центральный процессор (601), память ПЗУ, которая хранит код операционной системы (602), оперативную память (603) и энергонезависимую память (NVR, 604), используемую, как устройство хранения, аналогичное жесткому диску, и которая содержит, например, интегрированное программное обеспечение TLS. Шина системы (610) соединяет различные части модуля безопасности. Интерфейс связи с внешним миром (620) обеспечен портом ввода/вывода IO (605), совместимый со стандартами, такими как IS06816, USB, USBOTG, IS06816-12, MMC, пакет протоколов локальной сети, известной как Ethernet, IEEE 802.11 и т.д.

Микросхемы Ява, обычно называемые JAVACARD, являются конкретным классом модуля безопасности.

Изобретение относится к передаче данных, а именно к способу для создания защищенных данных при проведении сеанса связи между первым и вторым объектами. Техническим результатом является повышение безопасности данных. Технический результат достигается тем, что заявленный способ формирования защищающих данных для проведения безопасного сеанса связи между первым объектом и, по меньшей мере, вторым объектом по определенному протоколу для создания безопасных сеансов связи, в котором защищающие данные являются данными для выполнения протокола SSL или протокола TLS, содержит: установку указанным первым объектом защищенной смарт-карты, относящейся к указанному первому объекту; формирование, по меньшей мере, части указанных защищающих данных в указанной защищенной смарт-карте по командам, переданным указанным первым объектом; передачу указанных защищающих данных от указанной защищенной смарт-карты указанному первому объекту; и установление указанного безопасного сеанса связи между указанным первым объектом и указанным, по меньшей мере, вторым объектом с указанными ранее переданными защищающими данными. 3 н. и 1 з.п. ф-лы, 6 ил.

1. Способ формирования защищающих данных для проведения безопасного сеанса связи между первым объектом и, по меньшей мере, вторым объектом по определенному протоколу для создания безопасных сеансов связи, в котором защищающие данные являются данными для выполнения протокола SSL или протокола TLS, при этом указанный способ содержит:
стадию установки указанным первым объектом защищенной смарт-карты, связанной с указанным первым объектом;
стадию формирования, по меньшей мере, части указанных защищающих данных в указанной защищенной смарт-карте по командам, переданным указанным первым объектом;
стадию передачи указанных защищающих данных от указанной защищенной смарт-карты указанному первому объекту; и
стадию установления указанного безопасного сеанса связи между указанным первым объектом и указанным, по меньшей мере, вторым объектом с указанными ранее переданными защищающими данными,
и в котором указанная стадия формирования содержит:
стадию передачи указанным первым объектом, по меньшей мере, одного сообщения, направленного к уровню «ЗАПИСИ», используемому указанной защищенной смарт-картой, при использовании команды, реализованной в указанной смарт-карте и переданной указанным первым объектом;
стадию получения указанным первым объектом, по меньшей мере, одного сообщения от указанного уровня «ЗАПИСИ»;
стадию вычисления набора ключей указанной смарт-картой;
стадию сбора указанного набора ключей, доступных указанному первому объекту от указанной защищенной смарт-карты;
стадию восстановления идентификатора защищенного сеанса связи.

2. Способ формирования по п.1, в котором указанная защищенная смарт-карта включает виртуальную машину.

3. Устройство со смарт-картой для формирования защищающих данных, для выполнения безопасного сеанса связи между первым объектом и, по меньшей мере, вторым объектом согласно протоколу для установления безопасных сеансов связи, в котором указанные защищающие данные составляют данные для выполнения протокола SSL или TLS, и в котором указанное устройство содержит:
средство установки указанным первым объектом указанного устройства, относящегося к указанному первому объекту;
средство формирования, по меньшей мере, части указанных защищающих данных по командам, переданным указанным первым объектом;
средство передачи указанных защищающих данных указанному первому объекту;
и в котором указанное средство формирования содержит:
средство для получения от указанного первого объекта, по меньшей мере, одного сообщения, предназначенного уровню «ЗАПИСИ», используемому в указанной защищенной смарт-карте, при использовании команды, реализованной в указанной смарт-карте и переданной указанным первым объектом;
средство для передачи указанному первому объекту, по меньшей мере, одного сообщения от указанного уровня «ЗАПИСИ»;
средство для вычисления набора ключей указанной смарт-картой;
средство для передачи указанного набора ключей, доступных указанному первому объекту;
средства для восстановления идентификатора защищенного сеанса связи.

4. Машиночитаемый носитель, содержащий продукт компьютерной программы, который считывается компьютером, в котором указанный продукт содержит команды кода программы, которые при их выполнении на компьютере осуществляют формирование защищающих данных для проведения безопасного сеанса связи между первым объектом и, по меньшей мере, вторым объектом, по определенному протоколу для создания безопасных сеансов связи, в котором защищающие данные являются данными для выполнения протокола SSL или протокола TLS, при этом указанный способ содержит:
установку указанным первым объектом защищенной смарт-карты, относящейся к указанному первому объекту;
формирование, по меньшей мере, части указанных защищающих данных в указанной защищенной смарт-карте по командам, переданным указанным первым объектом;
передачу указанных защищающих данных от указанной защищенной смарт-карты указанному первому объекту; и
установление указанного безопасного сеанса связи между указанным первым объектом и указанным, по меньшей мере, вторым объектом с указанными ранее переданными защищающими данными.