Java Card: создаём Supplementary Security Domain для защиты ключей ISD

В предыдущей публикации на Хабре автор рассматривал механизмы безопасной персонализации апплета, встроенные непосредственно в смарт-карту. Такой подход позволял решить сразу две задачи: не разрабатывать собственный защищённый операционный сценарий (ЗОС) и не тратить ресурсы на его отладку. Однако у этого решения обнаружился существенный недостаток — оно порождает ещё более серьёзную угрозу. Дело в том, что ключи ISD (Issuer Security Domain) предоставляют полный контроль над смарт-картой. Если такие ключи окажутся в руках злоумышленника — человека с «горячим сердцем, холодной головой и грязными мыслишками», как образно выражается автор, — то, по его словам, «наш офис — его офис». Иными словами, компрометация ключей ISD означает потерю контроля над всем жизненным циклом карты.

Подробности

Java Card — это платформа, позволяющая выполнять Java-апплеты на смарт-картах и аналогичных защищённых устройствах. Ключевым элементом архитектуры является ISD — домен безопасности эмитента, через который осуществляется управление картой, загрузка и удаление апплетов, а также изменение ключей. Именно сосредоточение всех полномочий в ISD и создаёт описанный риск: утечка или передача ключей ISD третьим лицам фактически передаёт им управление картой. В качестве решения автор предлагает создать Supplementary Security Domain (SSD) — дополнительный домен безопасности. Идея заключается в том, чтобы не использовать ключи ISD напрямую для персонализации апплета, а задействовать отдельный домен с собственными ключами и ограниченными правами. Это позволяет изолировать критичные операции и снизить потенциальный ущерб в случае компрометации. В исходной публикации не приводятся идентификаторы CVE, номера версий или конкретные технические параметры уязвимостей — материал носит практический, обучающий характер и описывает подход к проектированию безопасности на уровне архитектуры Java Card. Автор обещает подробно разобрать процесс создания SSD в рамках цикла статей.

Что делать

Специалистам, работающим с Java Card, стоит рассмотреть следующие шаги: — Проанализировать текущую модель использования ключей ISD и оценить, какие операции действительно требуют полного набора полномочий. — Рассмотреть выделение отдельных доменов безопасности (SSD) для персонализации апплетов, чтобы не задействовать ключи ISD напрямую. — Ограничить круг лиц, имеющих доступ к ключам ISD, и применять принцип наименьших привилегий. — Обеспечить безопасное хранение и ротацию ключей, а также журналирование операций, связанных с управлением доменами безопасности. — Следить за продолжением цикла статей на Хабре, где будет описан практический процесс создания Supplementary Security Domain. Итог: предложенный подход с использованием Supplementary Security Domain позволяет снизить риски, связанные с концентрацией полномочий в ISD, и сделать архитектуру безопасности Java Card более устойчивой к компрометации ключей.

Источник: Хабр — Информационная безопасность