Процедуры генерации, обновления и отзыва сертификатов по протоколу set

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

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

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

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

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

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

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

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

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

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

·         соответствующий сертификату секретный ключ стал известен злоумышлен­нику;

·         сертификат принадлежит субъекту системы центра сертификации SET, по ка­ким-либо обстоятельствам прекратившему свое функционирование;

·         изменились учетные данные сертификата.

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

Список отозванных сертификатов CRL содержит следующие поля:

·         номер версии CRL (значение равно 2);

·         идентификатор алгоритма, с помощью которого подписывается CRL;

·         имя центра сертификации, сгенерировавшего CRL;

·         дату генерации CRL;

·         дату окончания действия CRL;

·         серийные номера отзываемых сертификатов;

·         дату начала действия CRL;

·         некоторые дополнительные данные (номер CRL, идентификационные дан­ные ключа центра сертификации, сгенерировавшего CRL, включая; имя эмитента ключа и его серийный номер).

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

·         список CRL-C, объединяющий списки RCA CRL, ВСА 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, передает вновь сгенерированный список в соответствующий центр сертификации уровня ВСА. RCA также передает 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, ССА Sig­nature 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, если он присутствовал в сообщении CardCInitRes;

·         язык, на котором должна быть написана запрашиваемая форма;

·         некоторые другие данные, например, «отпечатки» сертификатов, CRL и BCI, содержащиеся в системе владельца карты;

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

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

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

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

·         заполняет полученную регистрационную форму, включая в нее свое имя, срок действия карты, адрес (account billing address) и любую другую информацию, которая, по мнению эмитента карты, является необходимой для идентификации владельца карты (например, разовый пароль для идентификации владельца карты);

·         генерирует случайное число Sp включаемое в регистрационную форму;

·         генерирует по случайному закону пару симметричных ключей Kp и Kz;

·         объединяет заполненную регистрационную форму, Cardholder Public Key и ключ Кр подписывает эти данные с помощью Private Signature Key и далее шиф­рует все получившиеся в результате описанных в этом пункте операций данные с помощью ключа Kz;

·         ключ Kz вместе с номером карты шифруются ключом ССА Public Key-Exchange Key и передаются ССА;

9.    ССА, получив сообщение CertReq, с помощью ССА Private Signature Key расшиф­ровывает значение Kp, далее расшифровывает регистрационную форму и ключ Kz, проверяет цифровую подпись владельца карты. Далее ССА идентифицирует вла­дельца карты (например, по соответствию номера карты разовому паролю, предоставлен­ному ранее эмитентом карты центру сертификации). ССА генерирует случайное число Sy, которое комбинируется вместе с числом S, для формирования секрета карты S. Значение S хэшируется вместе с номером карты и сроком ее действия в значение, которое использу­ется в сертификате владельца, карты (это делается для того, чтобы номер карты не мог стать известным торговой точке в результате получения сертификата открытого ключа владельца карты). При, этом из полученного значения идентификатора сертификата вла­дельца карты невозможно установить номер карты, даже если известен секрет S , и срок действия карты. Наоборот, если известен секрет карты, номер карты и срок ее действия, значение идентификатора сертификата вычисляется легко.

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

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

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

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

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

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