主要領域
セキュリティ
主要領域 の観点では、「セキュリティ」の調査・分析は、記事を主要な領域ごとに整理し、インターネット基盤、運営・政策、接続市場、デジタル資本といった関心分野を追いやすくします。このページでは、関連記事、公開証拠、機関、企業、人物、地域的な影響、運用上の依存関係、市場の文脈をまとめ、別々のカテゴリページに散らばりがちな情報を一覧で確認できます。また、対象領域の説明、関与しうる主体の類型、市場・制度の文脈、シグナルを比較する際に参照すべき資料も示します。運用者、アナリスト、制度・政策の関係者は、同じ領域がイベント、プロフィール、市場の変化、公開証拠、地域依存、長期的なインフラ判断に、時間を追ってどのように現れるかを確認できます。
ケースファイル
署名は検証できた。それでも承認者は分からない：RFC 9591
障害後に残ったのは、対象メッセージ、グループ公開鍵、そして有効な Schnorr 署名だけだった。署名能力がしきい値を超えて使われたことは分かる。だが、どのメンバーが参加し、何を確認し、どの権限で同意したかは復元できない。RFC 9591の FROST は複数の署名シェアを一つの通常署名へ畳み込む。帰属を必要とする組織は、その前段の証拠を別に保持しなければならない。
ケースファイル
EdDSA対応と書いてあっても、曲線はまだ決まっていなかった：RFC 9864
能力表に同じアルゴリズム名が並んでも、同じ処理を実行できるとは限らない。`EdDSA` だけでは Ed25519 と Ed448 のどちらを扱えるか分からないからだ。RFC 9864は曲線とハッシュを含む名前へ進める。だが新しい名前は、実装や有効化、鍵の拘束、相互運用の成功まで保証しない。
ケースファイル
バックアップは鍵と一緒に昨日の状態まで戻した：RFC 9802
復旧した署名装置が正しい秘密鍵を持ち、有効な署名を返した。それだけでは復旧成功とは言えない。別の装置が同じワンタイム索引をすでに使っていれば、検証に通る二つの署名が安全性の前提を壊す。RFC 9802は X.509 に HSS と XMSS を識別させるが、署名者の状態履歴までは証明しない。
IETF
送る前の言葉は誰のものか――RFC 9787の下書き暗号化とコミットメント境界
これは仮想の場面だ。一台の端末で書きかけた文章が自動保存され、数分後、別の端末で同じメールボックスを開くと、その続きが現れる。しかし、その同期が成功したからといって予定受信者が文章を読めるわけではないし、著者が書かれた内容にすでに責任ある意思表示をしたことにもならない。RFC 9787 が下書き暗号化について引く重要な線は、まさにこの途中状態にある。保存と送信は同じメッセージの前後ではあっても、権限、可視性、そしてコミットメントの状態は同じではない。
北米のクラウドサービストレンド
CISA の是正期限経過、PaperCut が緊急パッチから保守ビルドへ移行
PaperCut の新しい保守ビルドで管理者はバージョン記録を明確にできるが、サイトサーバーとセカンダリサーバーの確認は引き続き必要だ。
IETF
暗号化できた断片が、メール全体を安全にするわけではない：RFC 9787
メール画面は一つでも、その内部には本文、添付、転送されたメッセージ、署名、暗号化層が別々の境界で存在する。RFC 9787 が求める一つの暗号学的サマリーは、この複雑さを隠すための万能印ではない。Crypto Payload を連続して包む層だけを、ひとまとまりとして説明するための表示である。
ケースファイル
五つの表記を通過した同じ対象：RFC 9804で署名されたバイトは何か
RFC 9804 は、SPKI S-expression を人が読む表記、通信向け表現、正規バイト列、実装固有のメモリ構造に分ける。見た目の同一性は証拠の同一性ではない。署名対象と、その後の解釈・認可・実行を示すには、各変換を別々に記録する必要がある。
記事
APNICのハニーネットが記録した127万件は「攻撃」ではなくイベントだ
APNIC 62で示されたダッカ大学の観測は、意図的に公開した1台のサーバーを有力なセキュリティセンサーに変えた。ただし、同じ127万という数字に「攻撃」「攻撃イベント」「イベント」という三つの名前を載せることはできない。
IETF
TLS再ネゴシエーションの修復はプロトコルを直したが、展開記録までは直していない
TLS の再ネゴシエーション問題は、単なる古い暗号方式の欠陥ではなかった。同じ接続上で続けて行われるハンドシェイク同士を暗号学的に結び付ける仕組みがなかったため、攻撃者が先に置いたアプリケーションデータの前に、別の利用者の認証コンテキストを接続できた。RFC 5746はその境界を修復し、TLS 1.3は再ネゴシエーション自体を廃止した。しかし、仕様の公開は、稼働中の全経路が修復済みだという証明ではない。
IETF
Transform は合意された。それでも replay はまだ拒否されていない：RFC 9827
RFC 9827 は、IKEv2 の Transform Type 5 を ESN の有無という狭い選択から、シーケンス番号の性質を表す契約へ広げた。その契約が示すのは SA のパケットがネットワークへ入る時点までであり、受信側の anti-replay 方針や実際の破棄結果までは保証しない。
IETF
ログ行は解析できた。しかし接続を読む権限は証明されていない：RFC 9850
RFC 9850 は TLS の診断用シークレットに共通の書式を与えた。小さな文法が大きな観測能力を運ぶからこそ、構文、許可、保管、利用、廃棄を一つの「デバッグ」に畳み込んではならない。
IETF
Verifier が購読しても、証拠の鎖には七つの検査が残る
IETF の草案は、ネットワーク機器のアテステーションを断続的な照会からイベントの流れへ変えようとしている。観測は速くなる。しかし、署名付き通知の到着は、測定から業務上の結果までを一度に証明しない。
IETF
新しいエントロピーはセッションに入った。それでも復旧には双方向の証明が要る
通常の TLS 1.3 KeyUpdate は、すでに存在する秘密の連鎖を次へ進める。Extended Key Update の草案は、稼働中のセッション内でもう一度鍵交換を行い、新しい共有秘密を後継状態に混ぜる。それは侵害後の復旧機会をつくるが、過去の状態が消えたことやアプリケーションが戻ったことまでは証明しない。
ケースファイル
パラメータ集合は検証できても、署名状態は証明されない：RFC 9858
RFC 9858 は HSS/LMS に新しいハッシュと安全強度の選択肢を加えた。しかし、ステートフル署名の核心は変わらない。検証者が一つの署名を正しいと判定できても、並行処理、障害復旧、古いバックアップ、鍵の枯渇を通じて同じワンタイム葉が二度使われていないことまでは分からない。
グローバルのクラウドサービストレンド
Let’s Encryptの99.21%は、稼働サービスのシェアではない
IP 証明書の新しい調査は発行の集中を示した。ただし、証明書を数えることと、それに依存するサービスを数えることは別の作業だ。
グローバルのクラウドサービストレンド
Cloudflareの旧耐量子APIは残るが、設定はもう変わらない
自動鍵交換の停止と、利用を認めるアルゴリズムの変更は別の操作だ。旧 API を使う運用手順には、その区別が必要になる。
アジア太平洋の国内通信事業者
TESS と Docomo、太陽光発電所監視向けセキュリティを試験
TESS は Docomo との実証で、不審な SIM 通信を遠隔で遮断し、接続が切れた際に太陽光発電所の監視をどう継続するかを検証する。
欧州・中東の機関トレンド
ENISA、CRA 報告は立ち上げ時に手動提出へ
ENISA は11月11日から CRA 報告プラットフォームを開始するが、当初は API の自動提出に対応せず、製造者はプラットフォーム上で手動での報告提出が必要になる。
IETF
CDN に一段追加すると、同じ印の意味が変わる
正規の内部処理でも、リクエストは同じ事業者の識別子を繰り返し持ち得る。CDN-Loop が示すのは、印を消さずに運ぶ責任と、その履歴を証明できることとの違いだ。
IETF
接続経路を変えたあと、ポータルは何を同じ端末とみなすのか
同じ端末から同じ URI を開いても、サーバーに見える接続の条件は変わりうる。キャプティブポータルのセッションを支えるのは固定の番号ではなく、各構成要素が維持する期限付きの対応関係である。