Редакция 4 NIST SP 800-63B вышла в июле 2025 года, предыдущая отозвана — значит, всё написанное по старому тексту описывает документ, которого больше нет. Новая редакция сохранила то, ради чего руководство и читают: три уровня доверия к аутентификации, каждый изложен списком проверяемых требований, а не прилагательным.
AAL3 — тот уровень, который имеют в виду, когда говорят, что аутентификация должна быть серьёзной. Приложить его к устройству самообслуживания полезно, потому что результат распадается на три части: требования, которые выполняются дословно; требования, которые неприменимы, потому что закрываемой ими угрозы здесь нет; и одно, которое не выполняется вовсе, если оборудование выбирали без оглядки на него.
Формулировки ниже даны в нашем переводе, ссылка на оригинал в конце.
Что выполняется дословно
Допустимые сочетания аутентификаторов заданы узко:
Аутентификация на AAL3 ДОЛЖНА требовать одного из следующих сочетаний: многофакторная криптографическая аутентификация; однофакторная криптографическая аутентификация в сочетании с паролем либо с биометрическим сравнением.
Сертификат на аппаратном токене, разблокируемый PIN-кодом, который проверяет сам токен, — это первое из сочетаний. PIN здесь фактор активации аутентификатора, а не секрет, куда-либо передаваемый.
Больше всего работы делает требование к ключу. В сводной таблице уровней экспортируемость ключа разрешена на AAL1 и AAL2 и запрещена на AAL3, а причина изложена в тексте:
криптографические аутентификаторы, используемые на AAL3, обязаны обеспечивать аппаратно защищённую изолированную среду, предотвращающую утечку или извлечение ключей аутентификации. Поскольку синхронизируемые аутентификаторы требуют экспортируемости закрытого ключа, синхронизируемые аутентификаторы НЕ ДОЛЖНЫ использоваться на AAL3.
Эта строка отделяет аппаратный токен от файла с удостоверением, и проверяется она прямо на устройстве: объект ключа либо сообщает о себе как о неизвлекаемом и никогда не извлекавшемся, либо нет. Синхронизируемые ключи доступа, которые редакция 4 в остальном признаёт на AAL2, здесь исключены поимённо.
Ещё два требования ложатся чисто. Протокол аутентификации на AAL3 должен быть устойчив к повторному воспроизведению — challenge-response таков по построению. И каждая аутентификация и повторная аутентификация должна демонстрировать намерение хотя бы от одного аутентификатора: вставить токен и ввести PIN — осознанное действие человека, а не то, что выполнит фоновый процесс.
Что неприменимо, а не выполнено
Здесь читать нужно аккуратнее. AAL3 требует от криптографического аутентификатора фишинг-устойчивости, и руководство признаёт ровно два способа её получить:
Признаются два метода фишинг-устойчивости: привязка к каналу и привязка к имени проверяющей стороны.
Привязка к каналу требует «установить аутентифицированный защищённый канал с проверяющей стороной» и связать идентификатор этого канала с выводом аутентификатора. Привязка к имени связывает вывод с аутентифицированным идентификатором проверяющей стороны. Оба способа предполагают, что проверяющая сторона находится где-то ещё — и что атакующий может встать на её место.
То же допущение сказано и прямо: обмен между заявителем и проверяющей стороной должен идти по одному или нескольким аутентифицированным защищённым каналам.
На устройстве без связи никакого «где-то ещё» нет. Проверяющая сторона — та самая машина, перед которой стоит инженер, и обмен не пересекает сеть. Привязывать нечего к чему: нет ни канала, ни удалённого имени, потому что нет и удалённой стороны, за которую можно себя выдать.
Это отличается от выполнения меры, и честнее сказать, что угроза не исчезла, а сместилась. Место фишинга занимает подменённое устройство: изменённое железо или программа, показывающая убедительное приглашение и забирающая то, что выдаёт токен. Привязка к каналу против этого не помогла бы, даже будь она возможна. Отвечают за это доверенная загрузка, целостность программного обеспечения и физическая защита корпуса — другие меры, в других документах, и довод, который придётся выстроить, а не позаимствовать.
Что не выполняется
AAL3 задаёт планку и самому оборудованию:
Однофакторные и многофакторные аутентификаторы, используемые на AAL3, ДОЛЖНЫ быть валидированы на соответствие требованиям FIPS 140 уровня 1 или выше в целом.
И то же со стороны проверки: криптография проверяющей стороны на AAL3 должна быть валидирована по FIPS 140 уровня 1 или выше.
Это не вопрос проектирования. У токена, сертифицированного по национальной схеме, отличной от американской, — а таких на рынке, который обслуживает этот продукт, большинство, — валидации FIPS 140 нет, и никакая правильность протокола её не заменит. На таком оборудовании AAL3 в написанном виде недостижим, и поставщик, утверждающий обратное, либо не читал требование, либо надеется, что не прочитаете вы. Там, где применяются токены с валидацией FIPS 140, требование закрывается выбором оборудования, а не программной обвязкой вокруг него.
Повторная аутентификация мягче, но сказать о ней стоит. На AAL3 общий срок до повторной аутентификации должен быть не более 12 часов, а срок бездействия — желательно не более 15 минут. Сервисная сессия на машине обычно много короче 12 часов, так что жёсткий предел не мешает. А бездействие относится к настройкам сессии и блокировки экрана в операционной системе — ровно как в разборах PCI DSS и ISO/IEC 27002: механизм входа эту меру себе приписывать не вправе.
Честные границы
SP 800-63 — руководство, адресованное федеральным ведомствам США. Органа, выдающего значок «соответствует AAL3», не существует, и ни один продукт не несёт уровень сам по себе: уровень доверия — свойство процесса аутентификации в развёрнутом виде, и оценивает его та организация, которая на него полагается. Tessera такого заявления не делает.
Ценность руководства в точности. Оно даёт язык, на котором «сильная аутентификация» превращается в список — неизвлекаемые ключи, устойчивость к повтору, подтверждённое намерение, валидированное оборудование, ограниченный срок сессии, — и на каждый пункт можно ответить «да», «нет» или «неприменимо, и вот почему». Выше три ответа «да», один «неприменимо» и один «нет, пока не куплены другие токены». Оценщику это полезнее заявления.
Источники
- NIST SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management (июль 2025, заменяет отозванный SP 800-63B) — выше приведены разделы 2.3 и 3.2
- Требование 8 PCI DSS на офлайн-устройствах — та же граница по простаивающей сессии в предписывающем стандарте
- Когда точка принятия решения недостижима — другой документ, предполагающий достижимую центральную сторону