Обеспечение безопасности платежных систем на основе протокола SSL
Протокол SSL (Secure Socket Layer)[3GPP TR 21.905: Vocabulary for 3GPP Specifications.] предназначен для безопасного обмена информацией между клиентом и сервером по открытым каналам связи. Из приведенной табл. 10.1 ясно, что SSL является промежуточным звеном между сеансовым и транспортным уровнями в семиуровневой модели OSI, что, с одной стороны, обеспечивает его полную аппаратно-программную независимость, а с другой - позволяет накладываться на другие протоколы, обеспечивающие защиту информации на физическом уровне.
| Номер уровня | Название уровня |
|---|---|
| 7 | Прикладной |
| 6 | Представления |
| 5 | Сеансовый |
| SSL | |
| 4 | Транспортный |
| 3 | Сетевой |
| 2 | Канальный |
| 1 | Физический |
SSL версии 3.0 явился основой для протокола TLS (Transport Layer Security), отличающегося от SSL незначительными деталями. В дальнейшем изложении под термином SSL будут пониматься оба протокола.
10.1. Обмен данными в SSL
Процесс обмена данными при помощи протокола SSL представлен на рис. 10.1.
Всякий раз, когда клиент подсоединяется к серверу, начинается сеанс SSL. В рамках каждого сеанса возможно несколько соединений. Если клиент подсоединяется к другому серверу, новый сеанс начинается без разрыва текущего. При возврате к первому серверу пользователь может возобновить соединение с использованием ранее установленных параметров либо создать новое соединение. Для предотвращения атак SSL предполагает ограничение времени действия сеанса (как правило, 24 часами), по истечении которого сеанс прекращается, и для дальнейшего общения с сервером необходимо создать новый сеанс.
Сеанс SSL характеризуется следующими значениями.
- Идентификатор сеанса (Session_ID) - случайное число, генерируемое на стороне клиента и позволяющее вернуться к уже установленному сеансу.
- Сертификаты узла (Client_Certificate и Server_Certificate) - сертификат участника информационного взаимодействия в соответствии со стандартом ISO/IEC 9594-8[3GPP TR 21.905: Vocabulary for 3GPP Specifications.].
- Метод сжатия - алгоритм сжатия передаваемых данных. Поддерживаемые алгоритмы указаны в RFC 3749[EMV ICC Specification for Payment Systems.].
- Спецификация шифра - определяет параметры криптоалгоритмов:
- для обмена ключами и проверки их подлинности: криптосистема с открытым ключом RSA, протокол выработки общего секретного ключа Диффи—Хеллмана (Diffie—Hellman), DSA (Digital Signature Algorithm), Fortezza.
- для симметричного шифрования: RC2, RC4, DES, 3DES, IDEA, AES;
- для хеширования: SHA, MD5.
- Секретный ключ сеанса (Master_Secret) - разделяемый клиентом и сервером секретный ключ.
- Флаг возобновления - параметр, определяющий возможность сохранения выбранных параметров для нового соединения в рамках текущего сеанса.
- Соединение SSL характеризуется следующими значениями.
- Случайные числа (Client_Random и Server_Random), применяемые при выработке общего секретного ключа.
- Ключи для шифрования/расшифрования информации (Client_Write_Secret = Server_Read_Secret и Server_Write_Secret = Client_Read_Secret).
- Ключи для подписи сообщений (секретные Server_ MAC_Write_Secret и Client_MAC_Write_Secret).
- Векторы инициализации (Server_IV и Client_IV) - синхропосылки для блочных алгоритмов шифрования.
- Два последовательных числа для сервера и клиента, предотвращающие атаки перехвата и повтора сообщения.
10.2. Протоколы SSL
SSL включает в себя четыре протокола, которые представлены на рис. 10.2:
- Handshake;
- Record;
- Alert;
- CCS (Change Cipher Specification).
Handshake. Данный протокол предназначен для взаимной аутентификации клиента и сервера, установки сеанса или соединения.
Установка сеанса, схематично представленная на рис. 10.3, как правило, инициализируется клиентом при помощи сообщения ClientHello (иногда инициатором выступает сервер, посылая сообщение HelloRequest, символизирующее о том, что сервер готов к процедуре Handshake), в котором клиент передает следующие параметры:
- версия SSL, поддерживаемая клиентом;
- идентификатор сеанса - значение, по которому впоследствии можно возобновить сеанс;
- случайное число Client_Random;
- список алгоритмов сжатия, шифрования и хеширования информации, поддерживаемых клиентом.
В ответ на это сообщение сервер высылает сообщение ServerHello, содержащее следующие параметры:
- версия SSL, поддерживаемая сервером;
- случайное число Server_Random;
- список алгоритмов сжатия, шифрования и хеширования информации, которые будут использоваться при реализации сеанса или соединений.
Кроме этого сообщения сервер высылает свой сертификат. В том случае, если используемые алгоритмы требуют сертификата клиента, сервер высылает клиенту запрос на сертификат - CertificateRequest. Затем сервер высылает клиенту сообщение ServerHelloDone, символизирующее об окончании передачи сообщения ServerHello.
Если клиент не поддерживает алгоритмы, предложенные сервером, или не выслал свой сертификат в ответ на соответствующий запрос, то установка сеанса прерывается. В противном случае клиент проверяет сертификат сервера, генерирует Pre_Master_Secret, зашифровывает его на открытом ключе сервера, полученном из сертификата последнего, и отсылает полученное значение в сообщении ClientKeyExchange. Сервер расшифровывает полученное сообщение при помощи своего секретного ключа и извлекает Pre_Master_Secret. Таким образом, обе стороны (клиент и сервер) обладают тремя значениями - Server_Random, Client_Random и Pre_Master_Secret и могут выработать Master_Secret по схеме, представленной на рис. 10.4.
После этого обе стороны посылают сообщение Finished, представляющее собой зашифрованные на секретном ключе Master_Secret параметры сеанса и символизирующее о завершении процесса установки нового сеанса.
На рис. 10.5 схематично представлена установка соединения.
Она начинается с отправки клиентом сообщения ClientHello, в котором содержится идентификатор сеанса и сгенерированное случайное число Client_Random. Сервер ищет полученный идентификатор в таблице текущих сеансов. Если данный идентификатор отсутствует, это означает, что сеанс истек или не был установлен. В этом случае запрос клиента отклоняется. Если же идентификатор существует, то соединение может использовать алгоритмы сжатия, шифрования и хеширования, которые были определены для сеанса, если установлен соответствующий флаг. В противном случае осуществляется выбор алгоритмов по аналогии с установлением нового сеанса.
В ответ на сообщение ClientHello сервер высылает сообщение ServerHello, содержащее Server_Random. Зная Server_Random, Client_Random и Master_Secret клиент и сервер могут выработать значения, характеризующие текущее соединение ( рис. 10.6).
Завершается установка соединения посылкой клиентом и сервером сообщений ChangeCipherSpec, подтверждающих принятие обеими сторонами алгоритмов сжатия, шифрования и хеширования информации и сообщений Finished, символизирующих об окончании процесса установки нового соединения.
Record. Данный протокол предназначен для преобразования данных, передаваемых сеансовым уровнем транспортному и обратно. Преобразование данных происходит по схеме, приведенной на рис. 10.7.
Передаваемая отправителем информация разбивается на блоки размером не более 2^14 + 2048 байт каждый. Затем каждый блок сжимается при помощи выбранного алгоритма сжатия. После этого вычисляется MAC каждого блока и прикрепляется к последнему. Полученные фрагменты последовательно нумеруются для предотвращения атак, зашифровываются при помощи выбранного алгоритма и передаются на транспортный уровень. Получатель расшифровывает полученные фрагменты, проверяет последовательность следования их номеров и целостность сообщений. Затем фрагменты распаковываются и объединяются в единое сообщение.
CSS. Протокол CSS состоит из единственного сообщения, разрешающего протоколу Record осуществлять преобразование данных с использованием выбранных алгоритмов.
Alert. Данный протокол формирует сообщения об ошибках, возникающих в процессе передачи данных или установки сеанса или соединения. В зависимости от характера ошибок будет выдано предупреждение или разорвано соединение/сеанс. Примеры ошибок приведены в табл. 10.2.
| Название | Описание |
|---|---|
| access_denied | сертификат отозван во время действия сеанса/соединения |
| bad_certificate | ошибка сертификата |
| bad_record_mac | неправильный MAC |
| certificate_expired | просроченный сертификат |
| certificate_revoked | отозванный сертификат |
| certificate_unknown | неизвестный сертификат |
| close_notify | добровольное прекращение сеанса отправителем |
| decode_error | ошибка разбиения на блоки/объединения блоков |
| decompression_failure | ошибка декомпрессии сжатого блока |
| decrypt_error | ошибка расшифрования, связанная с неудачей проверки подписи |
| decryption_failed | ошибка расшифрования, вызванная некорректным заданием параметров при зашифровании сообщения |
| export_restriction | ошибка, вызванная экспортными ограничениями |
| handshake_failure | невозможно установить общие параметры соединения |
| illegal_parameter | некорректные параметры сеанса/соединения |
| insufficient_security | недостаточный уровень секретности алгоритмов на стороне клиента |
| internal_error | внутренняя ошибка |
| no_renegotiation | ошибка, вызванная невозможностью завершить протокол Handshake |
| protocol_version | версия протокола клиента не поддерживается сервером |
| record_overflow | длина блока сообщения превышает значение 2^14+2048 байт |
| unexpected_message | несвоевременно полученное сообщение |
| unknown_ca | некорректная подпись центра сертификации |
| unsupported_certificate | неподдерживаемый сертификат |
| user_canceled | прерывание протокола Handshake клиентом |
10.3. Использование SSL в платежных системах
Большинство электронных платежных систем, в частности интернет-магазины, используют в своей работе web-браузеры. Учитывая, что SSL встроен практически во все известные web-браузеры, обеспечение безопасности передаваемых данных в 99% случаев[3GPP TR 21.905: Vocabulary for 3GPP Specifications.] осуществляется на его основе. Однако следует отметить следующие отрицательные стороны SSL, которые необходимо учитывать при принятии решения об использовании данного протокола при организации защищенного канала взаимодействия между участниками электронных платежных транзакций.
- Отсутствие аутентификации покупателя. Несмотря на то что в протоколе SSL заложена возможность запроса сертификата покупателя, аутентификация покупателя является опциональной и, как правило, не осуществляется, что делает невозможным использование SSL при операциях с банковским счетом.
- Аутентификация продавца по URL. Сертификат, предоставляемый продавцом, свидетельствует лишь о связи последнего с указанным URL, при этом нет никакой информации о взаимодействии продавца и банка, обслуживающего указанную платежную систему.
- Открытость реквизитов покупателя. Несмотря на то что вся информация, передаваемая в рамках SSL, является зашифрованной, данные о банковских реквизитах покупателя попадают к продавцу в открытом виде.
- Экспортные ограничения протокола. Несмотря на то что в 1999 г. Государственный Департамент США принял решение о снятии экспортных ограничений, некоторые браузеры поддерживают протокол SSL с экспортными ограничениями, касающимися длины ключей для алгоритмов шифрования информации, что существенно снижает защищенность передаваемых данных.