Токены PKCS#11: сертификаты и закрытые ключи

[Disasm]

Хотел задать вопрос про аппаратную начинку ваших токенов, но вопрос отпал сам собой.

Программно-аппаратный токен lsToken входит в состав семейства токенов LS11. В качестве ключевого носителя используется обыкновенная флешка — USB-флеш-накопитель.

А нормальных аппаратных токенов у вас вообще никаких нет? А то такой как-то стрёмно использовать даже для "домашних" применений.

[timzi]

Мне не очевидны приведенные Вами аргументы за такую новую схему работы с ключевыми парами. Соответствующий сертификат надо искать «по-старому» — перебором по телу открытого ключа из сертификата.

Схема со связкой тройки CKO_CERTIFICATE, CKO_PRIVATE_KEY, CKO_PUBLIC_KEY по CKA_ID работает для любого алгоритма. Работает уже очень давно.

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

Объекты можно защитить от изменения задав CKA_MODIFIABLE в CK_FALSE. Иначе где гарантия что, не только CKA_ID но еще и тело ключа кто-то подменил.

[saipr]

Интересно, как вы можете подменить тело сертификата? Никак — только положить новый сертификат. Как можно подменить «тело ключа» закрытого, если он неизвлекаемый? Но если вы подмените тело, то это будет другой ключ. Именно об этом и идет речь. Любая подмена, модификация при использовании описанных алгоритмов тут же ее обнаружит!!!

[rsashka]

Если не изменяет память, то CKA_EXTRACTABLE и CKA_MODIFIABLE это разные атрибуты.
И если установлен только первый, то извлечь значение нельзя, а вот заменить можно.

[saipr]

Первое, современные токены не обращают внимание на эти флаги для закрытого ключа. Он просто неизвлекаемый и неизменяемый. Ну а дальше, изменили что-то и что? Это уже не тот ключ и нетот сертификат. Цепочка порушилась.

[rsashka]

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

[saipr]

А сертификат как подменить? Он же имеет подпись от корневого! И т… д. Хотя, если в УЦ свои люди, то конечно, как там в "Гении".

[rsashka]

Если в УЦ свои люди, то ничего менять ненужно. Сразу запишут все, что требуется.
А вот возможность модификации объектов на токене, это потенциальная уязвимость, возможность эксплуатации которой зависит от конкретного ПО и его логики работы.

[saipr]

В чем уязвимость то, кроме потери сертификата и ключа. Мне их подменили и они перестали для меня и других существовать. Идем на УЦ и получаем новый сертификат. Подмена это не использование. Это разные вещи.

[rsashka]

Откуда я могу знать про возможности использования подобной уязвимости в абстрактной системе?
Я написал, что неизвлекаемость и немодифицируемость, это разные атрибуты. А уж можно такой сценарий эксплуатировать или нет, это вопрос к аналитикам.

[saipr]

неизвлекаемость и немодифицируемость, это разные атрибуты.

Вы абсолютно правы — это абсолюто разные атрибуты. И семантика у них разная.

[saipr]

Графическая оболочка утилиты P11Conf: