Конфигурация. После аутентификации перед терминалом КТ открывает ему доступ к группам данным. Т переносит факт успешной аутентификации КТ на группы данных, считая их подлинными -- связанными с КТ и неизмененными после связывания.
Проблема. После компрометации личного ключа КТ можно навязать Т любые группы данных.
Решение (обсуждаемое). Группы данных хэшируются, список хэш-значений подписывается специально выделенным Центром. Именно такая схема используется в ICAO/ePassport (см. https://www.icao.int/publications/Documents/9303_p10_cons_en.pdf). Подписанный список называется Security Data Object (SDO).
Недостатки решения. Первый недостаток -- отсутствие связывания SDO с КТ. Без связывания скомпрометированный КТ может передать Т корректный SDO другого КТ. По-хорошему, нужно хэшировать группы данных вместе с серийным номером КТ (он указывается в облегченном сертификате КТ, а этот сертификат проверяется при аутентификации КТ).
Вторая проблема -- организация доступа Т к SDO. Т имеет доступ к SDO целиком (иначе он не сможет проверить подпись), и в то же время Т имеет выборочный доступ к группам данным. Если группа содержит низкоэнтропийную информацию (например, дату рождения), то Т может ее восстановить, перебирая всевозможные варианты, хэширую варианты и сравнивая хэш-значения с эталонным, представленным в SDO. Политика управления доступа к группам данным достаточно легко преодолевается. По-хорошему, нужно пописывать каждую группу по отдельности. SDO разрастается.
Третья проблема -- доступ к группам на запись. Теперь каждый раз перед записью Т должен обновить список хэш-значений и переподписать его у Центра. Сценарий кажется труднореализуемым. Более того, предыдущий SDO может циркулировать наряду с новым. По-хорошему, надо его отзывать, что еще больше усложняет ситуацию.
Четвертая проблема. Если мы не доверяем группам данным, которые хранятся на борту КТ, то естественно не доверять и другим хранимым объектам. Например, объекту Name, который прямо переносится в сертификат X.509. По-хорошему, нужно подписывать и этот объект. В будущем появятся другие чувствительные объекты, их снова нужно подписывать. КТ превращается в контейнер для хранения подписанных объектов. Криптографическая логика аутентификации, реализуемая КТ, приобретает номинальное значение. Все равно мы доверяем только подписи Центра. Верен ли такой подход? В определенных случаях (например, ePassport) -- да. Но в целом, в том числе для случая eID, -- нет.
Соображения и выводы.
Основная задача eID -- аутентификация владельца КТ в информационных системах. Вспомогательная задача -- управление идентификационными данными владельца. Данные могут быть динамическими (чтение + запись), важно организовать работу с ними без участия третьей стороны (Центра). Да, с Центром и его подписями надежнее, но это другая топология. Она годится для статических данных ePassport, но не для динамических данных eID.
Да, возможна подмена данных eID, но только после компрометации механизмов аутентификации (личного ключа КТ). Защита от последствий компрометации -- стоп-листы серийных номеров скомпрометированных КТ, акцент на связывание сеанса аутентификации с номером КТ, а не с прочитанными группами данных.
Конфигурация. После аутентификации перед терминалом КТ открывает ему доступ к группам данным. Т переносит факт успешной аутентификации КТ на группы данных, считая их подлинными -- связанными с КТ и неизмененными после связывания.
Проблема. После компрометации личного ключа КТ можно навязать Т любые группы данных.
Решение (обсуждаемое). Группы данных хэшируются, список хэш-значений подписывается специально выделенным Центром. Именно такая схема используется в ICAO/ePassport (см. https://www.icao.int/publications/Documents/9303_p10_cons_en.pdf). Подписанный список называется Security Data Object (SDO).
Недостатки решения. Первый недостаток -- отсутствие связывания SDO с КТ. Без связывания скомпрометированный КТ может передать Т корректный SDO другого КТ. По-хорошему, нужно хэшировать группы данных вместе с серийным номером КТ (он указывается в облегченном сертификате КТ, а этот сертификат проверяется при аутентификации КТ).
Вторая проблема -- организация доступа Т к SDO. Т имеет доступ к SDO целиком (иначе он не сможет проверить подпись), и в то же время Т имеет выборочный доступ к группам данным. Если группа содержит низкоэнтропийную информацию (например, дату рождения), то Т может ее восстановить, перебирая всевозможные варианты, хэширую варианты и сравнивая хэш-значения с эталонным, представленным в SDO. Политика управления доступа к группам данным достаточно легко преодолевается. По-хорошему, нужно пописывать каждую группу по отдельности. SDO разрастается.
Третья проблема -- доступ к группам на запись. Теперь каждый раз перед записью Т должен обновить список хэш-значений и переподписать его у Центра. Сценарий кажется труднореализуемым. Более того, предыдущий SDO может циркулировать наряду с новым. По-хорошему, надо его отзывать, что еще больше усложняет ситуацию.
Четвертая проблема. Если мы не доверяем группам данным, которые хранятся на борту КТ, то естественно не доверять и другим хранимым объектам. Например, объекту Name, который прямо переносится в сертификат X.509. По-хорошему, нужно подписывать и этот объект. В будущем появятся другие чувствительные объекты, их снова нужно подписывать. КТ превращается в контейнер для хранения подписанных объектов. Криптографическая логика аутентификации, реализуемая КТ, приобретает номинальное значение. Все равно мы доверяем только подписи Центра. Верен ли такой подход? В определенных случаях (например, ePassport) -- да. Но в целом, в том числе для случая eID, -- нет.
Соображения и выводы.
Корректировка BTOK. Не требуется.