генерация сертификата

В самых общих чертах процедуры генерации сертификатов для участников транзакции ЭК выглядят следующим образом.

Чтобы получить сертификат своего открытого ключа, владелец карты направляет специальный запрос в адрес своего ССА. В ответ ССА передает владельцу карты сертификат своего открытого ключа.

Владелец карты передает ССА номер своей карты, зашифрованный на открытом ключе ССА, и в ответ получает регистрационную форму, соответствующую данной карте.

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

ССА с помощью эмитента идентифицирует владельца карты и генерирует для него сертификат открытого ключа.

Более детальное описание процедуры генерации сертификата владельца карты будет приведено далее.

Процедура получения сертификата ключа ТП является более простой по сравнению с процедурой генерации сертификата владельца карты.

На первом этапе ТП обращается в МСА со специальным запросом на получение сертификата своего открытого ключа.

В ответ ТП получает открытый ключ МСА и регистрационную форму.

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

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

В отличие от владельца карты ТП и платежный шлюз должны получить сертификаты открытых ключей типов Digital Signing Key и Key-Exchange Key.

ЦС уровня End-Entity получают сертификаты своих открытых ключей в ЦС уровня GCA или ВСА, GCA в ВСА, ВСА в RCA. Процедуры получения этих сертификатов не формализованы стандартом SET. Запрос сертификата осуществляется с помощью сообщения формата PKCS# 10, а сертификат от вышестоящего ЦС поступает в формате PKSC#7.

Открытый ключ подписи ЦС уровня RCA распространяется среди производителей прикладного программного обеспечения, работающего с протоколом SET. ПО включает сертификат корневого ключа. В отличие от сертификатов участников, этот сертификат подписывается с использованием закрытого корневого ключа подписи.

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

Специальная процедура смены ключа предусмотрена для Certificate Signing Key ЦС уровня RCA. Этот корневой ключ подписи сертификатов генерируется в двух экземплярах — действующая пара ключей R, и пара ключей R2, которая будет действовать после окончания срока действия пары R В сертификате открытого ключа пары R,, подписанном закрытым ключом этой же пары, содержится значение хэш-функции открытого ключа пары R2. Поэтому, получив новую пару ключей R2, участник транзакции ЭК проверяет равенство значений хэш-функции нового открытого ключа со значением, содержащемся в старом сертификате. Таким образом подтверждается подлинность полученного нового сертификата открытого ключа подписи.

Рекомендуемые сроки обновления пар асимметричных ключей приведены в таблице.

Соответствующие этому примеру сроки хранения сертификатов приведены в таблице ниже.

Результаты, приведенные в последней таблице, получаются из предположения, что каждый вышестоящий ЦС выдает сертификат нижестоящему ЦС в последний день действия сертификата вышестоящего ЦС. Проиллюстрируем сказанное на примере расчета срока действия сертификата открытого ключа Certificate Signing Key ЦС уровня RCA. Поскольку в нашем примере среди всех участников транзакции ЭК наибольшим сроком действия обладает ключ владельца карточки (3 года), то рассмотрим следующую цепочку. Предположим, что владелец карты получил сертификат своего ключа в последний день действия Certificate Signing Key ЦС уровня CCA, который, в свою очередь, получил сертификат на этот ключ в последний день действия ключа Certificate Signing Key ЦС уровня GCA. ЦС уровня GCA получил свой сертификат для ключа Certificate Signing Key в последний день действия ключа Certificate Signing Key ЦС уровня ВСА, а последний, в свою очередь, получил сертификат на этот ключ в последний день действия сертификата ключа Certificate Signing Key ЦС уровня RCA. В результате для проверки сертификата владельца карты необходимо хранить сертификаты открытых ключей Certificate Signing Key ЦС уровней RCA, ВСА, GCA и CCA соответственно 7, б, 5 и 4 года.

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

  • соответствующий сертификату секретный ключ стал известен злоумышленнику;
  • сертификат принадлежит субъекту системы ЦС SET, по каким-либо обстоятельствам прекратившему свое функционирование;
  • изменились учетные данные сертификата.

Как уже отмечалось ранее, списки отозванных сертификатов CRL генерируют и поддерживают RCA, ВСА, GCA, PCA. При этом RCA CRL содержит отозванные сертификаты, принадлежащие RCА и ВСА, ВСА
CRL содержит отозванные сертификаты GCA, CCA, MCA, PC A, GCA
CRL — отозванные сертификаты CCA, MCA, PCA, обслуживаемых данным GCA, PCA CRL — отозванные сертификаты платежных шлюзов, обслуживаемых данным РСА. Список CRL всегда подписывается ЦС, сгенерировавшим данный CRL.
Список отозванных сертификатов CRL содержит следующие поля:

  • номер версии CRL (значение равно 2);
  • идентификатор алгоритма, с помощью которого подписывается CRL;
  • имя ЦС, сгенерировавшего CRL;
  • дату генерации CRL;
  • дату окончания действия CRL;
  • серийные номера отзываемых сертификатов;
  • дату начала действия CRL;
  • некоторые дополнительные данные (номер CRL, идентификационные данные ключа ЦС, сгенерировавшего CRL, включая имя эмитента ключа и его серийный номер).

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

  • список CRL-C, объединяющий списки RCA CRL, BCA CRL, GCA CRL;
  • списки РСА CRL.

Во время проведения транзакции ЭК при получении сертификата шлюза владелец карты проверяет по спискам РСА CRL, не является ли данный сертификат отозванным, а по списку CRL-C для владельцев карты —
не является ли отозванным сертификат какого-нибудь ЦС, участвующего в цепочке получения сертификата платежного шлюза. Владельцу карты нет необходимости проверять, является ли отозванным сертификат торгового предприятия, в котором совершается транзакция ЭК. Это связано с двумя обстоятельствами:

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

От владельца карты требуется только проверка по списку CRL-C всех сертификатов, используемых при определении подлинности сертификата ТП.

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

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

Наконец, платежный шлюз должен проверять по CRL-C отсутствие отозванных сертификатов в цепочке сертификатов ТП и владельца карты. За распространение и хранение списков CRL отвечают ЦС и платежные шлюзы. В процессе выдачи и обновления сертификатов ЦС сообщают владельцам карт, ТП и платежным шлюзам актуальные на данный момент времени списки CRL. Актуальные списки сообщаются участникам транзакции ЭК и в процессе проведения SET-транзакции. При этом ТП актуализирует списки CRL, получая недостающие списки от платежного шлюза, владелец карты обновляет списки в диалоге с ТП. Кроме того, в рамках SET существует специальная пара сообщений между ТП и платежным шлюзом (Gateway Certificate Request/Response Messages), с помощью которой, в том числе, можно получить обновленные версии списков CRL.

Процедура обновления списков отозванных сертификатов использует каталог всех актуальных на данный момент времени списков CRL в данной платежной системе. Такой каталог называется Brand CRL Identifier (или, сокращенно, BCI). Он состоит из списка номеров всех актуальных на данный момент CRL и подписывается с помощью CRL Signing Key ЦС уровня ВСА. Владельцы карт и ТП получают актуальные значения BCI в процессе сертификации-обновления своих ключей от своих ЦС (соответственно — ССА и МСА), а также во время проведения транзакции ЭК в ответных сообщениях, получаемых, соответственно, от ТП и платежного шлюза. ЦС и платежные шлюзы, в свою очередь, получают BCI вместе со всеми ассоциированными с данным BCI списками CRL из ЦС уровня ВСА. В соответствии с протоколом SET ЦС и платежные шлюзы обязаны обновлять каталог BCI на ежедневной основе.

Каталог BCI используется для избирательного предоставления только недостающих списков CRL. Например, во время проведения транзакции ЭК владелец карты передает ТП данные о каталоге BCI, актуальном для владельца карты на данный момент времени. ТП возвращает в ответном сообщении актуальный каталог, имеющийся на стороне ТП, а также в общем случае не все списки BCI, ассоциированные с данным CRL, а только те списки, которых не хватает владельцу карты. Такая технология позволяет уменьшить объем сообщений, циркулирующих между участниками транзакции ЭК. Каждый ЦС, поддерживающий генерацию списков CRL, передает вновь сгенерированный список в соответствующий ЦС уровня ВСА. RCА также передает CRL, содержащий скомпрометированные корневые ключи, во все во все ЦС уровня ВСА.

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

1. Владелец карты генерирует запрос (в терминах SET — сообщение CardCInitReq), содержащий идентификатор пары сообщений (запроса-ответа на получение сертификата владельцем карты; в терминологии протокола SET — RRPID), идентификатор транзакции (в терминологии SET — LID-EE), генерируемый владельцем карты для учета запроса в системе владельца карты, идентификатор платежной системы (в терминологии SET — Brand ID), случайное число Chall-EE и в качестве параметров «отпечатки» всех сертификатов (включая Root certificate), списков CRL и BCI, хранящихся в системе владельца карты. Под «отпечатком» (по-английски — Thumbprint) здесь понимается значение хэш-функции от соответственно сертификата, CRL, BCI. Хэш-функция применяется для того, чтобы уменьшить объем передаваемой информации, в то же время с высокой вероятностью однозначно идентифицируя хэшируемую информацию.

2. ССА обрабатывает полученное от владельца карты сообщение CardCInitReq, производя следующие проверки:

  • проверяет равенство значений RRPID в заголовке и содержимом полученного сообщения;
  • запоминает «отпечатки» сертификатов, CRL, BCI из сообщения CardCInitReq, а также LID-EE и Chall-EE.

3. После этого ССА генерирует ответ (в терминологии SET — CInitCardRes), состоящий из подписываемых с помощью ССА Private Signature Key данных. Данные содержат «отпечатки» сертификатов, CRL, BCI из сообщения CardCInitReq, LID-EE, Chall-EE, параметрически идентификатор запроса LID-CA, генерируемый ССА, «отпечаток» сертификата ССА Key-Exchange ключа, сертификаты ССА Key-Exchange Key, CCA Signature Key, а также «отпечаток» BCI в случае, если в сообщении CardCinitreq «отпечаток» BCI отсутствовал. На этом заканчивается этап инициализации получения сертификата владельцем карты.

4. Владелец карты (точнее, конечно, его программное обеспечение), получив сообщение CardCInitRes, проверяет сертификаты ССА Key-Exchange Key и ССА Signature Key, а также цифровую подпись ССА. Поскольку цифровая подпись ССА относится к данным, включающим Chall-EE, ее проверка эквивалентна аутентификации ССА владельцем карты. Таким образом, проверив цифровую подпись, содержащуюся в полученном от ССА сообщении, владелец карты убеждается в том, что в процессе сертификации своего открытого ключа он имеет дело с подлинным центром сертификации.

5. Далее владелец карты передает в адрес ССА запрос на получение регистрационной формы (в терминологии SET — RegFormReq). При формировании этого запроса владелец карты создает данные RegFormReqData, содержащие:

  • новый идентификатор RRPID сообщений на запрос/ответ регистрационной формы;
  • идентификатор транзакции LID-EE из CardCInitReq;
  • новое случайное число Chall-EE2;
  • идентификатор транзакции LID-CA, если он присутствовал в сообщении Card СI nit Res;
  • язык, на котором должна быть написана запрашиваемая форма;
  • некоторые другие данные, например, «отпечатки» сертификатов, CRL и BCI, содержащиеся в системе владельца карты.

После этого владелец карты по случайному закону генерирует симметричный ключ Кг с помощью которого шифруются данные Reg-FormReqData. Симметричный ключ К, вместе с номером карты, в свою очередь, закрываются CCA Public Key-Exchange Key и передаются ССА.

6. ССА, получив сообщение RegFormReq, с помощью своего Private Key-Exchange Key расшифровывает номер карты и значение ключа Kj и далее с помощью ключа Ку дешифрует RegFormReqData.

7. По номеру карты и языку владельца карты ССА определяет соответствующую регистрационную форму для владельца карты, подписывает эту форму вместе с другими данными (включая Chall-EE2) своим ключом Private Signature Key и отправляет ее владельцу карты.

8. Владелец карты вновь проверяет сертификат ключа Private Signature Key и цифровую подпись ССА и производит следующие действия:

  • заполняет полученную регистрационную форму, включая в нее свое имя, срок действия карты, адрес (account billing address) и любую другую информацию, которая, по мнению эмитента карты, является необходимой для идентификации владельца карты (например, разовый пароль для идентификации владельца карты);
  • генерирует случайное число S,, включаемое в регистрационную форму;
  • генерирует по случайному закону пару симметричных ключей
  • объединяет заполненную регистрационную форму, Cardholder Public Key и ключ К2, подписывает эти данные с помощью Private Signature Key и далее шифрует все получившиеся в результате описанных в этом пункте операций данные с помощью ключа К3;
  • ключ К3 вместе с номером карты шифруются ключом CCA Public Key-Exchange Key и передаются ССА (это сообщение в терминологии SET называется CertReq).

9. ССА, получив сообщение CertReq, с помощью ССА Private Signature Key расшифровывает значение К3, далее расшифровывает регистрационную форму и ключ К2, проверяет цифровую подпись владельца карты. Далее ССА идентифицирует владельца карты (например, по соответствию номера карты разовому паролю, предоставленному ранее эмитентом карты центру сертификации).

ССА генерирует случайное число S2, которое комбинируется вместе с числом S, для формирования секрета карты S. Значение S хэшируется вместе с номером карты и сроком ее действия в значение, которое используется в сертификате владельца карты (это делается для того, чтобы номер карты не мог стать известным ТП в результате получения сертификата открытого ключа владельца карты). При этом из полученного значения идентификатора сертификата владельца карты невозможно установить номер карты, даже если известен секрет S и срок действия карты. Наоборот, если известен секрет карты, номер карты и срок ее действия, значение идентификатора сертификата вычисляется легко.

После этого ССА создает сертификат открытого ключа владельца карты, подписывая его своим Private Signature Key, и формирует ответ CertRes, содержащий значение S2, сертификат владельца карты и другую информацию (например, логотип платежной системы и/или банка-эмитента). Сформированное сообщение подписывается ключом К2 и отправляется владельцу карты.

10. Владелец карты с помощью ранее запомненного значения ключа К2 расшифровывает полученное сообщение CertRes, проверяет сертификат своего открытого ключа и формирует значение секрета S, которое в дальнейшем используется владельцем карты при проведении транзакций ЭК, о чем будет рассказано далее.

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

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

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

3. Наконец, на третьем этапе клиент заполняет регистрационную форму, включая в нее свой открытый ключ, и направляет ее владельцу карты. Взамен клиент получает от ССА сертификат открытого ключа и некоторый секрет, используемый для маскирования номера карты в сертификате, а также для дальнейшей аутентификации владельца карты его банком-эмитентом.