Неверная проверка атрибутов docValidity и ageValidity

Пороговые даты для проверки docValidity и ageValidity присылаются в КТ с помощью APDU инициализации BAUTH. Данная APDU отправляется клиентской программой и терминал не знает значений пороговых дат. В результате терминал получает результат сравнения неизвестных ему срока действия КТ и возраста владельца КТ с неизвестными пороговыми датами, выбранными клиентской программой. Результаты проверки docValidity и ageValidity для включения в билет сервера идентификации становятся необоснованными.

Дополнительно, если владелец КТ может манипулировать датой для клиентской программы (переводя время на компьютере), то он может навязать клиентской программе такие пороговые даты, при которых терминал всегда получит результат, что КТ является действительным и возраст владельца удовлетворяет нужному критерию

При инициализации протокола BAUTH в данных команды обязательно передаются данные (дата) для проверки атрибута DocumentValidity (срок действия карты), а также могут передаваться данные для проверки атрибутов AgeVerification (возраст) и RegionVerification (место жительства). Непосредственно проверка атрибутов, для которых данные передавались через команду инициализации протокола, производится терминалом через вызов команды Verify.

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

Терминал может быть двух типов:

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

При использовании удаленного терминала есть риск, что КП может быть скомпрометирована (т.е. злоумышленник может поменять данные команды инициализации протокола BAUTH). Поэтому, если терминал не доверяет КП, то он может проверить срок действия карты и другие атрибуты через чтение соответствующих групп данных (DG), т.е. после успешной аутентификации по протоколу BAUTH терминалу следует прочитать нужную группу данных командой "Read Binary" и выполнить проверку атрибута (например, проверить, что срок действия карты не истек). После проверки результат может быть включен в билет аутентификации. Недостатком такого сценария является то, что терминалу передаются значения групп данных (например, точная дата рождения), при этом пользователь должет дать согласие на раскрытие необходимых терминалу групп данных и у терминала в его сертификате должны быть установлены соответствующие права на чтение. Отметим, что удаленные терминалы, как правило, лучше защищены и поэтому имеют повышенный уровень доступа.

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

Таким образом, возможность использования команды Verify для проверки атрибутов зависит от того, доверяет терминал КП или нет. Введение команды Verify для проверки атрибутов позволяет более гибко проверять атрибуты КТ и выдавать права доступа терминалам.

Отметим, что для немецкой карты, данные для проверки атрибутов DocumentValidity, AgeVerification и RegionVerification также передаются в команде инициализации протокола аутентификации терминала (см. TR-03110 part 3) и могут проверяться через вызов команды Verify.

При использовании удаленного терминала есть риск, что КП может быть скомпрометирована (т.е. злоумышленник может поменять данные команды инициализации протокола BAUTH).

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

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

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

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

Отметим, что для немецкой карты, данные для проверки атрибутов DocumentValidity, AgeVerification и RegionVerification также передаются в команде инициализации протокола аутентификации терминала (см. TR-03110 part 3) и могут проверяться через вызов команды Verify.

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

Фактически может быть 3 ситуации:

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

В ситуации 1 никаких проблем с использованием Verify нет.

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

В ситуации 3 для использование Verify (проверка атрибутов) необходимо, чтобы данные для проверки атрибутов были включены в запрос аутентификации Req_ПС (формируется прикладной системой, которая и определяет, какие атрибуты для нее важно проверить). В этом случае хэш-значение от этих данных будет включено в команду инициализации протокола BAUTH (объект "хэш-значение запроса аутентификации") и будет использоваться в качестве сообщения hello_T при выполнении протокола BAUTH (см. п. 10.4 стандарта). Это обеспечит необходимый контроль целостности данных для проверки атрибутов и результаты проверки для включения в билет сервера идентификации будут обоснованными.

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

Отметим, что все расмотренные сценарии соответствуют стандарту. Возможно следует дать уточняющие комментарии об использовании данных из Req_ПС для формирования объекта AuthAuxData, который передается в команду инициализации BAUTH (12.2.5).

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

Для ситуации 2 прикладная система должна сверх положенных ей прав запросить доступ к паспортным данным и возрасту - при регистрации на СИ ей могут отказать в превышении прав. Далее владелец КТ должен дать разрешение на использование прикладной системой прав сверх положенных для конкретного сервиса. В случае злонамеренного владельца - он не даст таких прав. Поэтому в ситуации 2 - проблема остается.

В ситуации 3 - проблема также остается: Req_ПС передается в КТ в виде хэш-значения, и это не позволяет контролировать целостность переданных параметров в команде инициализации BAUTH никакими дополнительными обменами: кроме явной передачи Req_ПС и явного его парсинга в КТ

В ситуациях 2, 3 следует или контролировать целостность данных для проверки атрибутов, передаваемых при инициализации (например, использовать их значение при вызове bake-kdf в BAUTH), или позволить терминалу отправлять параметры напрямую в КТ по защищенному соединению (в команде Verify вместо OID отправлять DiscretionaryDataTemplate с OID и датой)

Почему в команду Verify вместо OID не отправляется DiscretionaryDataTemplate с OID и датой?

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

Мы принципиально допускаем существование злонамеренного терминала?

Это разрушает все: пропадает доверие прикладных систем к билетам СИ, которые выпущены на основе данных от терминалов.

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

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

Мы принципиально допускаем существование злонамеренного терминала? Это разрушает все: пропадает доверие прикладных систем к билетам СИ, которые выпущены на основе данных от терминалов.

Хорошо. Но в ходе дискуссии по вопросу #56 существование ненадежных терминалов отстаивалось. Рекомендуется придерживаться единой логики.

Предложение. Добавить в приветственное сообщение hello_T протокола BAUTH объект AuthAuxData.

Детали:

В 10.4 (Выпуск билета аутентификации/Шаги) на шаге 5 сказать, что hello_T кроме h_КП / h_СИ может включать дополнительные данные, подразумевая AuthAuxData.
В 12.2.15 (Инициализация BAUTH) объявить что hello_T = h_КП || AuthAuxData.

Предлагается внести уточнения по протоколу BPACE:

В 10.4 на шаге 3 таблицы 6 упоминается сообщение M0_BPACE, при этом в 8.3.1 сказано: "Соответственно не отправляется и не обрабатывается сообщение M0". Следует писать, что на шаге 3 отправляется не <<M0_BPACE, M1_BPACE>>, а сообщение <<M1_BPACE>>, у которого hello_B = ...
В команде инициализации протокола BPACE (см. 12.2.16) передаются обязательные объекты, а также могут передаваться необязательные объекты. Необязательными объектами являются: два объекта CertHAT, используемые для установки прав доступа к eID и eSign, и значение N, определяющее количество последовательных подписей, которые могут быть выработаны eSign без повторного подтверждения PIN. Если значение N подается на команду инициализации протокола, то следует его включать и в hello_B. В п. 12.2.16 следует уточнить, что передаваемые в команде объекты CertHAT и значение N следует использовать для формирования hello_B протокола, указать порядок включения в hello_B. Также следует внести соответствующие уточнения в 10.4.

Предлагается более радикальное решение.

В hello-сообщение протокола (BPACE или BAUTH) переносится все поле CDF целиком. Фактически CDF (настройки) косвенно подписываются сторонами протокола (КТ и КП). Сторонам проще работать с CDF целиком, не выделяя отдельные фрагменты. При усложнении семантики CDF логика сохранится, не нужно будет ничего менять.
В hello-сообщение BAUTH дополнительно включаются права доступа CertHAT = Chart_B. Эти те права, которые указывались в hello-сообщении BPACE. Эти права известны терминалу (вторая сторона BAUTH) согласно общей схеме аутентификации. Полностью BPACE.CDF переносить в BAUTH.hello нельзя, ведь терминал не знает всех договоренностей между КТ и КП. Не переносить CertHAT в BAUTH.hello также нельзя, ведь противник может навязать Т не те права, на которые согласился владелец.

Прототип решения: https://github.com/bcrypto/btok/commit/8e6a56c6faa49f975858ec2ea2e645420655e7d2.

Реализовано в #86.

bcrypto / btok

Неверная проверка атрибутов docValidity и ageValidity #81