Обновление точек доверия

[agievich]

Проблематика

Срок действия криптографического токена (КТ) может выходить за срок действия
корневого сертификата, записанного на токен. После перехода на новый корневой
сертификат подчиненные ему сертификаты терминалов не будут приниматься КТ и
работа с токеном будет заблокирована.

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

Предлагается использовать подход, предложенный в стандарте TR-03110/part3 [1].
Стандарт разработан в ФРГ, распространяется на ЕС.

В [1] в качестве точки доверия используется либо корневой сертификат,
либо связной или линк- сертификат. Оба сертификата принадлежат корневому УЦ.
Подпись корневого сертификата проверяется на собственном открытом ключе,
подпись линк-сертификата --- на открытом ключе корневого сертификата или
предыдущего линк-сертификата. Линк-сертификаты связаны друг с другом, отсюда и
название.

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

Далее мы описываем решение [1], дополняя его недостающими деталями.

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

Уточнения СТБ 34.101.79

Настоящий документ предполагает внесение в СТБ 34.101.79 следующих поправок:

1. В инфраструктуре КТ имеется единственный корневой УЦ. Идентификатор
   BYCA0NNN, который указывается в поле certAuthorityReference корневого
   сертификата, следует интерпретировать как "как корневой сертификат номер
   NNN". (В СТБ этот идентификатор интерпретировался как "сертификат корневого
   УЦ номер NNN").

2. При выпуске КТ в обращение на него записывается единственный корневой
   сертификат. (В СТБ допускается запись нескольких корневых сертификатов).

3. Сроки действия сертификатов:

   • корневой УЦ --- 5 лет;
   • подчиненный УЦ --- 6 месяцев;
   • терминал --- 3 дня;
   • КТ --- совпадает со сроком действия токена.

   (В СТБ сроки действия не определялись).

4. В СТБ 34.101.79[12.3.2] требуется, чтобы команда <PSO: Verify Certificate>
   выполнялась после команды <General Authenticate>, которая отвечает за
   инициализацию протокола BAUTH. Для загрузки линк-сертификатов вне контекста
   BAUTH разрешается прямой вызов <PSO: Verify Certificate>.

Линк-сертификаты: содержание

Линк-сертификатам назначаются последовательные серийные номера. Нумерация
ведется от 1, пропуски номеров не допускаются. Серийный номер 0 резервируется
для начального корневого сертификата. Серийные номера кодируются тремя
десятичными цифрами: 000, 001, 002 и т.д.

Серийный номер линк-сертификата NNN и предыдущий серийный номер MMM
указываются в полях certHolderReference и certAuthorityReference --- эти
поля должны принимать значения BYCA0NNN и BYCA0MMM соответственно.
Сертификат с номером MMM -- это пред-сертификат для линк-сертификата с
номером NNN.

Другие требования к содержанию линк-сертификатов:

1. Срок действия линк-сертификата --- 5 лет.

2. Дата начала действия линк-сертификата должна быть позже даты начала действия
   пред-сертификата.

3. Дата начала действия линк-сертификата должна быть не менее чем на 10 дней
   раньше даты окончания действия пред-сертификата.

4. Дата начала действия линк-сертификата не должна быть раньше даты его
   фактического выпуска.

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

5. Сроки действия линк-сертификата и пред-сертификата его пред-сертификата,
   если таковой имеется, не должны пересекаться.

6. Права доступа к прикладным программам eId и eSign в линк-сертификате
   должны совпадать с соответствующими правами в пред-сертификате.

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

Линк-сертификаты: выпуск

Корневой УЦ должен выпускать очередной линк-сертификат при приближении к
окончанию срока действия текущей точки доверия (корневого сертификата или
линк-сертификата). При выпуске линк-сертификата УЦ должен обеспечить
выполнение требований к его содержанию, перечисленных в предыдущем пункте.

При выпуске линк-сертификатов УЦ не должен допускать ветвлений --- ситуаций,
когда у двух различных линк-сертификатов совпадает пред-сертификат.

Вместе с линк-сертификатом УЦ должен выпускать корневой сертификат с тем же
ключом, тем же серийным номером, теми же правами доступа к прикладным
программам и тем же сроком действия.

В корневом сертификате оба поля certHolderReference и certAuthorityReference
должны принимать значение BYCA0NNN, где NNN --- серийный номер.

Примечание. Актуальный корневой сертификат (а не соответствующий ему
линк-сертификат) будет записываться на КТ при выпуске токена.

Загрузка линк-сертификата: терминал

При аутентификации перед КТ терминал передает токену цепочку сертификатов.
Цепочка начинается сертификатом, который непосредственно подчинен одному из
сертификатов корневого УЦ (точке доверия), и заканчивается сертификатом терминала.

Примечание. Если сертификат терминала выпускается корневым УЦ, то цепочка
будет включать только этот сертификат.

Сертификаты цепочки загружаются на КТ по-отдельности, друг за другом.
Используется команда <PSO: Verify Certificate> (см. СТБ 34.101.79[12.2.21]).
Каждый переданный сертификат проверяется, в случае ошибки загрузка цепочки и
вся аутентификация прерываются.

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

1. Cоставить список доступных линк-сертификатов и упорядочить их по возрастанию
   серийных номеров. Пусть (Cert_1,..., Cert_n) -- итоговый список.
2. Для i = n,..., 1:
   1. загрузить на КТ Cert_i;
   2. в случае успеха перейти к шагу 4.
3. Возвратить 0.
4. Для j = i + 1,..., n:
   1. загрузить на КТ Cert_j;
   2. в случае ошибки возвратить j - 1.
5. Возвратить n.

На шаге 2 устанавливается доверие одному из линк-сертификатов, а затем на шаге
4 это доверие распространяется на более поздние линк-сертификаты.
Алгоритм возвращает i, если удалось загрузить Cert_i и не удалось загрузить
сертификаты с большими серийными номерами. Возврат 0 означает, что не удалось
загрузить ни одного линк-сертификата.

Могут использоваться другие алгоритмы загрузки актуальных линк-сертификатов.
В частности, терминал может предварительно сузить список (Cert_1,..., Cert_n),
используя информацию о загруженных точках доверия из файла EF.CVCA
(см. далее).

Загрузку линк-сертификатов можно выполнять в рамках протокола BAUTH, после
вызова <General Authenticate>. В случае успеха загрузки можно перейти
к загрузке цепочку сертификатов терминала, оставаясь в рамках протокола.

Загрузка линк-сертификата: криптографический токен

КТ хранит в постоянной памяти от одной до двух точек доверия. Первоначальная
точка доверия записывается на КТ при выпуске токена -- это корневой
сертификат (самостоятельный или ассоциированный с линк-сертификатом). Точки
доверия добавляются и обновляются в процессе эксплуатации токена.

При обработке команды загрузки сертификата КТ выполняет все действия,
определенные в СТБ 34.101.79 (в том числе обновляет оценку текущей даты).

Дополнительные шаги после того, как сертификат признан действительным:

1. Разобрать поле certAuthorityReference. Если a) поле имеет вид BYCA0NNN
   (обрабатывается линк-сертификат) и b) порядковый номер NNN больше обоих
   порядковых номеров текущих точек доверия, то атомарно ("все или ничего")
   выполнить следующие шаги:
   1. если имеется 2 точки доверия, то удалить точку с наименьшим порядковым
      номером;
   2. добавить обрабатываемый линк-сертификат в список точек доверия.
2. Возвратить:
   1. OK, если загрузка сертификата выполняется в контексте протокола BAUTH
      (команде <PSO: Verify Certificate> предшествует команда <General Authenticate>);
   2. результат выполнения блока 1.1 -- 1.2 в противном случае.

Примечание. Поскольку линк-сертификат признан действительным, среди точек
доверия есть сертификат с предыдущим серийным номером. Отсюда следует, что
если КТ хранит две точки доверия, то это сертификаты с последовательными
серийными номерами. Хранение двух точек полезно для взаимодействия с
"отставшими" терминалами.

Файл EF.CVCA

Ссылки на актуальные точки доверия (корневые сертификаты или линк-сертификаты)
указываются в элементарном файле EF.CVCA. Ссылки представлены строкой октетов
одной из двух форм:

• CAR || 0x0000000000000000;
• CAR || CAR'.

Здесь CAR и CAR' --- поля certAuthorityReference точек доверия (8 октетов).

Строка первой формы соответствует случаю, когда на КТ хранится одна точка
доверия, строка второй формы --- когда хранится две точки. В обоих случаях файл
EF.CVCA состоит из 16 октетов.

При наличии двух точек доверия серийный номер CAR должен быть (на единицу)
больше серийного номера CAR'.

Файлу EF.CVCA должен быть назначен идентификатор 0x541C.

Должно быть разрешено чтение файла EF.CVCA в состояниях PS и AS.

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

Литература

[1] Technical Guideline TR-03110 "Advanced Security Mechanisms for Machine
Readable Travel Documents and eIDAS Token~--- Part 3: Common Specifications",
Version 2.21, 2016.

[agievich]

Модельные сертификаты (включая линк-сертификат): https://github.com/bcrypto/btok/blob/master/model/certs/init.sh.

[olegotory]

Опишем, каким образом выполняется аутентификация терминала перед криптографическим токеном (КТ) согласно TR-03110/part3, и приведем основные отличия от СТБ 34.101.79.

В TR-03110/part3 аутентификация терминала выполняется по защищенному соединению после успешной аутентификации по протоколу PACE (Password Authenticated Connection Establishment, установление соединения с аутентификацией по паролю). Для аутентификации по PACE может использоваться пароль CAN, PIN или PUK.

Для аутентификации терминала используется следующая последовательность команд:

1. MSE: Set DST.

2. PSO: Verify Certificate.

3. MSE: Set AT.

4. Get Challenge.

5. External Authenticate.

Команды 1 и 2 предназначены для проверки сертификатов и выполняются для каждого сертификата цепочки (линк-сертификата, сертификата подчиненного УЦ, сертификата терминала), а команды 3 - 5 предназначены для инициализации и выполнения протокола аутентификации терминала.

При выполнении команды 2 используется процедура проверки сертификата, которая обеспечивает, в том числе и обновление точек доверия.

При аутентификации терминала с использованием команд 3 - 5 применяется действительный сертификат терминала, переданный на шаге 2.

В случае, если требуется только обновить точки доверия, команды 1 и 2 могут быть вызваны без последующего выполнения команд 3 - 5.

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

Процедура проверки сертификата выполняется для каждого сертификата цепочки. Если у КТ отсутствует внутренний аппаратный таймер, то процедура включает следующие шаги:

1. Проверка сертификата. Для сертификата проверяется, что его подпись действительна и он не просрочен (дата окончания срока действия предшествует текущей дате КТ). Если проверки не пройдены, то процедура прерывается.

2. Обновление текущей даты. На основании даты вступления сертификата в действие обновляется текущая дата КТ.

3. Импорт открытого ключа и связанных с ним метаданных. Для целей дальнейшего использования в оперативную память КТ импортируются открытый ключ и связанные с ним метаданные, включая:

• идентификатор владельца сертификата (соответствует компоненту certAuthorityReference сертификата);

• роль и права доступа владельца сертификата (соответствует компоненту certHolderAuthorizationTemplate сертификата);

• дата выпуска сертификата (соответствует компоненту certEffectiveDate сертификата);

• дата окончания действия сертификата (соответствует компоненту certExpirationDate сертификата);

• расширения сертификата (соответствует компоненту certExtensions сертификата).

4. Обновление точек доверия. Если сертификат является линк-сертификатом, то импортированные ключ и метаданные устанавливаются в качестве новой точки доверия КТ (записываются в постоянную память). При этом точка доверия с истекшим сроком действия удаляется. Информация по актуальным точкам доверия отражается в файле EF.CVCA.

Для проверки первого сертификата из цепочки (линк-сертификата или сертификата подчиненного УЦ) должен использоваться открытый ключ, соответствующий точке доверия. Идентификатор certAuthorityReference данного открытого ключа возвращается при выполнении протокола PACE как результат обработки КТ последней команды протокола. Идентификатор возвращается только в том случае, если в команде инициализации протокола PACE был передан объект CertHAT, который используется для установки прав доступа к данным и сервисам прикладных программ КТ и который предполагает в дальнейшем выполнение аутентификации терминала. Может возвращаться до 2-x идентификаторов, соответствующих установленным в КТ точкам доверия. Идентификаторы открытых ключей точек доверия могут быть прочитаны из файла EF.CVCA напрямую.

В СТБ 34.101.79 для аутентификации терминала используется следующая последовательность команд:

1. MSE: Set AT.

2. PSO: Verify Certificate.

3. General Authenticate.

Команда 1 инициализирует протокол аутентификации терминала, команда 2 используется для проверки сертификатов и выполняется для каждого сертификата цепочки, а команда 3 - применяется для выполнения шагов протокола.

Сравнивая используемые в TR-03110 и СТБ 34.101.79 для аутентификации терминала команды и порядок их вызова можно видеть следующие отличия, связанные с проверкой сертификатов:

• в СТБ 34.101.79 проверка сертификатов выполняется после инициализации протокола аутентификации, а не до инициализации, как это предусмотрено в TR-03110;

• в СТБ 34.101.79 для проверки каждого сертификата цепочки используется одна команда, а не две команды, как это предусмотрено в TR-03110.

Отметим также, что в СТБ 34.101.79 при выполнении протокола BPACE (аналога протокола PACE) не предусмотрен возврат идентификаторов открытых ключей точек доверия, как это возможно в TR-03110.

[agievich]

Механизм раннего информирования о точках доверия в каомандах управления BPACE избавляет от необходимости прямого чтения EF.CVCA и, таким образом, повышает эффективность работы с КТ. Следует проработать применение механизма.

В связи с этим два вопроса.

1. Как нужно изменить команды BPACE для раннего информирования КП о точках доверия?
2. Можно ли изменить команды BAUTH для раннего информирования терминала?

[olegotory]

По поводу первого вопроса (изменение команды BPACE для раннего информирования КП о точках доверия).

Для выполнения шагов протокола BPACE используется цепочка из 2-x команд General Authenticate. В текущей редакции СТБ 34.101.79 при последнем вызове команды возвращается RDF = der(7C, der(83,M4) ), где M4 — сообщение протокола (является имитовставкой длины 8 октетов). Для информирования КП о точках доверия вместо текущего RDF можно возвращать RDF' = der(7C, der(83,M4) || der(84,CAR) [|| der(85,CAR')]).

Отметим следующие:

1. Размер нового RDF' увеличивается максимум на 20 октетов и не превышает 32 октета.

2. Для поддержки в КТ механизма раннего информирования о точках доверия можно поступить следующим образом:

• определить дополнительный объектный идентификатор протокола BPACE (протокола BPACE с передачей информации о точках доверия) ;
• при необходимости получения информации о точках доверия в команде <MSE: Set AT> (инициализация протокола BPACE) вместо стандартного идентификатора передавать новый идентификатор.

Отметим также, что протокол PACE/BPACE выполняется между клиентской программой (КП) и КТ. Поэтому после выполнения PACE/BPACE информация о точках доверия, доступных на КТ, должна быть передана от КП на терминал. В TR-03110 способ передачи такой информации никак не регламентируется.

[olegotory]

По поводу второго вопроса (изменение команд BAUTH для раннего информирования терминала).

Для команды "MSE: Set AT", используемой при инициализации протокола аутентификации терминала, не допускается возврат от КТ каких-либо данных (в компоненте RDF). Поэтому, в последовательности команд, используемой при аутентификации терминала, можно разрешить выполнение дополнительной команды, возвращающей доступные на КТ точки доверия. Данная команда должна вызываться после инициализации протокола BAUTH (команды "MSE: Set AT") и до проверки цепочки сертификатов (команды "PSO: Verify Certificate"). В качестве такой команды может использоваться, например, стандартная команда чтения данных "Get Data", для которой INS = CA, в P1||P2 содержится значение 0200 (возвратить информацию о точках доверия), CDF отсутствует, а в RDF возвращается содержимое файла EF.CVCA.

В этом случае, для аутентификации терминала с передачей от КТ информации о точках доверия должна использоваться следующая последовательность команд:

1. MSE: Set AT.
2. Get Data.
3. PSO: Verify Certificate.
4. General Authenticate.

Для аутентификации терминала вызов команды "Get Data" можно сделать необязательным. Можно также, как и для рассмотренной выше модификации протокола BPACE, ввести новый идентификатор протокола BAUTH (протокол BAUTH с передачей информации о точках доверия), который следует передавать в команде "MSE: Set AT" вместо стандартного идентификатора.