要約

  • draft-mittal-est-coap-ca-certs-00 は、工場で組み込んだメーカー信頼アンカーにより、運用CA証明書を含むCMS署名オブジェクトを検証する方式を提案する。個人提出の00版Internet-Draftであり、RFC、IETF合意、実装実績ではない。
  • ブートストラップの配送サーバーは未認証でもよい。TLS/DTLSはそこで搬送しか担わず、署名者の用途、エイリアス、シーケンス、有効期間、ローカル方針を通ったオブジェクトだけが候補になる。
  • CA束をインストールしても既存接続のサーバーは認証されない。クライアントは新しいTLS/DTLSセッションを開始し、そのサーバーを新アンカーで検証してから、登録などの通常EST処理へ進む。

ゼロタッチ導入には、最初の信頼をどこから得るかという円環がある。機器はサーバーを認証するためにCAを必要とする。一方、安全にCAを受け取るにはサーバーを先に認証したい。製造時点では、最終顧客のPKIがまだ存在しないことも珍しくない。

個人草案 draft-mittal-est-coap-ca-certs-00 は、信頼を接続からオブジェクトへ一時的に移す。機器にはメーカーの信頼アンカーとメーカー別エイリアスを置く。導入時にメーカーまたは認可された署名機関が、運用CA群をCMS SignedDataで保護する。ESTサーバーはその静的オブジェクトを配布する。

クライアントは、提示されたサーバー証明書をまだ受理できなくても、そのオブジェクトだけを取得できる。公開メタデータとして扱える場合には、平文HTTP/CoAPも候補に入る。安全性の根拠は配送路ではなく署名対象にある。

この設計を壊す最短経路は、検証成功を接続全体へ波及させることだ。CMSが正しくても、サーバー名は証明されない。暗号化されていても、相手の権限は成立しない。CAがインストールされても、証明書登録は承認されない。草案はこの拡張を明示的に止めている。

署名鍵が承認したのは内容であって配送者ではない

ManufacturerSignedCACerts には、版、エイリアス、単調増加するシーケンス番号、notBefore、notAfter、一つ以上のCA証明書が入る。CMS署名は構造全体を覆う。クライアントは署名証明書から工場内蔵アンカーまでのパスを構築し、その証明書がブートストラップCA束の署名に認可されているか確認する。

成功結果は限定的だ。「認められた鍵がこの正確なバイト列を保護した」と言える。DNS名の管理者、IPアドレスの運用者、HTTP/CoAP応答者の身元までは言えない。攻撃者のミラーが真正なオブジェクトを中継することさえ可能だ。

真正な中継は、公開オブジェクトの取得には使えるかもしれない。しかし、その中継へCSR、機器資格情報、長期識別子を送る理由にはならない。HTTPSでは /cacerts 取得だけ、EST-coapsでは /crts だけに操作を絞る。再登録、CSR属性、サーバー側鍵生成も許さない。

配布サーバーは同じ静的オブジェクトを同じメーカードメインの機器へ返せる。オンラインでメーカー署名鍵を持つ必要はない。要求ごとの動的署名を避けられる点は可用性と鍵保護の両方に効く。

ただし、監査記録は分離しなければならない。配布ログは送った事実、署名ログはオブジェクトの承認、機器ログは検証と採用を示す。「信頼できる発信元」という一語では、どの主体が何を決めたのか復元できない。

エイリアスは住所であり委任状ではない

HTTPSの例は /.well-known/est/{manufacturer-alias}/cacerts、CoAP側は /crts である。IANA Private Enterprise Numberから別名を作る案もあるが、00版は一つの構成を義務づけず、新規IANA登録も要求しない。

外側のパスだけを見て「このメーカーのもの」と判定すると、ルーティング情報が権限になる。そこでエイリアスは署名対象にも含まれる。クライアントは要求したエイリアスまたはローカルに定義した同等名と一致させる。不一致なら、署名が有効でもインストールしない。

一台のサーバーが複数メーカーを扱う場合、この検査は必須だ。別の信頼ドメイン向けに正しく署名された束を、そのまま転用する攻撃を止める。URIは対象を選び、署名は文脈を結び、ローカル設定は許される同値関係を決める。

証跡には、設定済みエイリアス、要求URI、署名内エイリアス、同値規則、CMSハッシュ、判定を残すべきだ。「HTTP成功」も「署名成功」も、単独ではこの機器の信頼ストアを変更できる根拠にならない。

古い正規品はロールバック攻撃に使える

署名は時間が経っても検証できる。運用CAが侵害され交換された後でも、旧CAを含む束の署名自体は正しい。攻撃者はその束を再生し、工場リセット後の機器を古い状態へ戻せる。

提案はシーケンス番号と有効期間を持つ。クライアントはエイリアスごとに最高受理番号を保存し、それより低い束を拒否するべきだ。信頼できる時刻があれば期間を必ず検査し、なければシーケンスを優先して、後で認証済み時刻を得た段階で期間を再評価する。

この仕組みでは、シーケンスの保存場所がセキュリティ境界になる。通常設定とともに消えるなら、リセット時に巻き戻し防止も消える。同一番号で内容が異なる場合、バックアップから古い状態を復元した場合、緊急に番号を下げたい場合の処理を先に決めなければならない。

キャッシュも時間問題を増やす。静的束はDoS耐性を高めるが、撤回後もCDNに残りうる。CDNが一ビットも変えず返しても、それが現在の正解とは限らない。完全性と新鮮さは別の証拠である。

必要な記録は、オブジェクトハッシュ、保護された番号、前回番号、時刻の信頼度、期間判定、キャッシュ年齢、方針版、変更後アンカー集合ハッシュを結ぶ。署名検証だけのメトリクスは最も起きやすい攻撃を見落とす。

ローカル方針はメーカーへの白紙委任を防ぐ

検証済み束は、運用アンカーを追加、置換、拡張できる。ただし草案はローカルの信頼アンカー管理方針を適用するよう求める。この二つはセットで読まなければならない。

メーカー署名は「製造時に認めた主体から提案が来た」と示す。既存ルートを削除してよいか、移行期間を設けるか、特定CAを拒むか、保守承認を要するかは運用者の決定だ。署名を自動命令に変えると、製造関係が将来の信頼を支配する常設制御路になる。

Lu Hengの最小初期仕様という考え方なら、共通にすべきものは局所検証可能な最低限に限られる。署名パス、専用用途、正確な内容、エイリアス、番号、期間は共通検査でよい。将来のCA選択、交代時期、障害対応は結果を負う事業者側へ残す。

実装は検証と変更の間に方針段階を置くべきだ。現在と提案後の集合ハッシュ、追加と削除、適用ルール、判断主体を記録する。拒否は正常な終端であり、その後に未認証サーバーで登録を続けてはならない。

新しい接続だけが新アンカーを試験する

アンカーを受理したら、クライアントは新たなTLS/DTLSセッションを作る。そこで初めて、新アンカーを使って運用サーバーの名前と証明書パスを検証する。

古い接続を継続すれば、相手が現れた時点と信頼方針が変わった時点が混ざる。ライブラリが証明書を再評価できても、ハンドシェイク、暗号パラメータ、エクスポータ値は元の文脈に属する。通常EST操作は新セッションに結びつける方が証拠として明確だ。

RFC 7030 は既に、最初の認証に失敗した状態で /cacerts を得るためTLSを暫定継続し、CAデータを帯域外で承認した後に新しい接続を使う流れを示す。00版はそのオブジェクト承認をメーカー署名へ置き換えるが、再接続は消さない。

RFC 9148 はESTをCoAP/DTLSへ移し、/cacerts を /crts に対応させる。制約機器向け搬送が可能になっても、応答した端点が運用登録者だとは限らない。

新セッションの記録には、期待名、サーバーチェーン指紋、採用アンカー、検証方針、結果、時刻を含める。登録要求はその記録を参照する。そうしなければ、CA束の受理とCSR受信サーバーの認証を区別できない。

証明書登録はさらに別の権限面である

サーバーを認証できても、CAが登録を承認するとは限らない。機器はCSRを作り、秘密鍵の保有を証明し、ドメインの方針を満たす必要がある。証明書が発行されても、属性が誤っていたり、導入に失敗したり、目的サービスへ到達できないことがある。

草案はESTの登録意味論、proof-of-possession、CA方針を変更しないと明記する。扱うのは運用CA証明書の配布だけだ。機器を認可せず、CSRを承認せず、証明書を発行せず、稼働結果を観測しない。

状態機械は、取得、署名者認可、新鮮性、ローカル承認、ストア変更、新セッション認証、登録承認、証明書設置、サービス観測を分けるべきだ。担当主体もロールバックも違う。

メーカーはブートストラップ署名、運用者はローカル方針、ESTサービスはサーバー身元と処理、CAは発行、実行系は結果を担う。一つの署名が全員の意思を代行することはない。

メーカー鍵は全フリートの支点になる

メーカー署名鍵が侵害されれば、対応アンカーを信頼する全機器へ不正なCA束を配れる。草案はHSM/KMS相当の保護、非エクスポート、専用証明書を推奨し、TLSサーバー、CA発行、ファームウェア署名との再利用を避ける。

用途分離は被害半径だけでなく権限の明確さにも効く。「メーカーまでチェーンできる」だけでは、その鍵がどの行為を許されたか分からない。クライアント方針はブートストラップ束署名という役割を明示して認可する必要がある。

重要なのは疑いが生じた後だ。特定エイリアスを止められるか。後継署名者を誰が認めるか。疑わしい束を受け入れた機器を列挙できるか。メーカー倒産後も所有者がCAを更新できるか。同じ侵害鍵だけが復旧命令を出せるなら独立した復旧ではない。

RFC 8995 と RFC 8366 のvoucherは、メーカーによるドメイン帰属の別方式である。主体、フレッシュネス、ローカル受理の比較には役立つが、00版をBRSKIや実装済み標準へ変える証拠ではない。

未認証の入口は安く応答できなければならない

通常認証前に要求が来るため、入口はDoS対象になる。草案は静的・事前計算オブジェクト、顧客別DB参照の回避、要求時署名の回避、送信元・プレフィックス・エイリアス・インスタンス単位の制限、DTLS cookie、GET限定、応答サイズと増幅の制御を挙げる。

これはブートストラップ段階を署名済み公開リポジトリとして設計せよ、という意味だ。個別計算や秘密情報の照会を持ち込むほど、最小方式から離れ、攻撃者へ資源を与える。

平文オプションは、完全性と秘密性の違いも示す。CMSは改ざんを防げるが、エイリアスとCA束は観測される。それが顧客名、地域、移行時期を示すなら、相手をまだ認証できなくてもTLS/DTLSによる秘匿が必要になる。

「ブートストラップ成功」を八つの証拠に分解する

証拠 最低限の内容 証明しないもの
製造由来 機器種別、アンカー指紋、保管、別名規則 現在のメーカー支配
オブジェクト権限 CMSハッシュ、チェーン、用途、結果 サーバー身元、新鮮性
範囲と時点 内外別名、番号、期間、時刻信頼度 ローカル採用
ストア変更 方針、差分、前後ハッシュ 新セッション認証
初期搬送 URI、提示証明書、暗号化、キャッシュ EST権限
新セッション 名前、チェーン、アンカー、結果 登録承認
登録 CSR、機器身元、鍵保有、CA判断 サービス稼働
稼働結果 証明書設置、ヘルス、対象サービス観測 次回束の正当性

分離すれば局所的に復旧できる。別名置換はCA全体を疑う必要がなく、サーバー設定不良は束の署名を無効にしない。登録失敗時も正しいアンカー移行を維持でき、署名鍵侵害時は影響した変更だけを追跡できる。

00版が示す有用な境界は単純だ。独立検証できるオブジェクトは未信頼の搬送路を通過できる。しかしオブジェクトの信頼は搬送路へ伝播しない。サーバー身元は、新アンカーで新しい握手が成功した時に初めて成立する。