Кратко

  • TLS-POK из RFC 9966 позволяет серверу показать знание открытого BSK устройства, а устройству — владение соответствующим закрытым ключом.
  • Стандарт намеренно не устанавливает, как сервер получил открытый ключ; успех обмена не доказывает законное владение устройством, корректную цепочку хранения или фактическое разрешение в сети.

У нового устройства может возникнуть замкнутый круг: для доступа через EAP нужна учётная запись, а для её получения нужен доступ. Owen Friel и Dan Harkins в RFC 9966 описали узкий стартовый механизм для проводной сети. TLS Proof of Knowledge, TLS-POK, использует эллиптическую Bootstrap Key, BSK, в обмене TLS 1.3 до выдачи учётных данных для последующей работы.

Роли ключа разделены. Закрытая часть BSK известна только устройству. Открытая часть известна устройству и его владельцу либо держателю и затем загружается на TLS-сервер его оператором. Сервер доказывает клиенту знание открытого ключа, а клиент доказывает серверу владение закрытым. Из открытого ключа выводится EPSK; далее клиент применяет BSK как raw public key. В этой точке протокол фиксирует отношение к криптографическому материалу, но не историю его поставки и не полномочия участников.

Именно предыдущий шаг RFC оставляет за рамками. Точный способ, которым TLS-сервер получил открытый BSK, не определён. Указаны лишь возможные варианты: сканирование QR-кода и загрузка BOM. Если QR-метка прикреплена к устройству физически, модель предполагает, что физическое владение означает законную собственность. Это допущение ускоряет ввод устройства, однако TLS не проверяет покупку, перевозку, передачу, целостность метки, инвентарный учёт или решение местной политики.

Из раздела безопасности следует практический риск. Клиент полагается на то, что его открытый BSK не стал широко доступен. Противник, узнавший ключ и сумевший направить клиента на свой сервер, может завершить TLS-POK и загрузить клиент в свою сеть. Ошибка возможна и раньше: подмена открытого ключа честного устройства ключом чужого устройства при bootstrap способна привести к тому, что нормальный сервер примет чужое устройство. Криптографический след будет верно проверять полученный ввод, но не его испорченную связь с вещью.

Детальные требования очерчивают, но не отменяют эту зависимость. Клиент не должен посылать открытый BSK, пока не обработает ServerHello и не проверит расписание ключей TLS; при неудачной PSK-проверке он прекращает обмен, не раскрывая ключ. Производителям следует выдавать уникальный BSK каждому устройству. Общий BSK не позволяет оператору различать устройства и удостовериться, что подключаются только конкретные разрешённые единицы. Это защита от раскрытия и смешения идентичностей, а не реестр собственности.

После успешной сессии сервер может выдать credential для будущей EAP-аутентификации. BSK применяется только при первоначальной загрузке. Поэтому происхождение открытого ключа, загрузка его на сервер, итог TLS, выпуск credential, решение EAP и исполнение на точке доступа должны оставаться разными, хотя и связанными событиями. Один успешный handshake не является квитанцией за всю цепочку.

Открытый профиль IETF связывает Harkins с RFC 9966, а публичная фотография признания IEEE 802.11 служит только ориентиром личности для редакционного портрета. Это не доказательство управления какими-либо сетями. Ценность соавторского решения в другом: оно делает стартовое доказательство полезным, не приписывая ему происхождение и ответственность, которые должны подтверждаться вне протокола.

Источники