Tim Hudson, OpenSSL Corporation 社長 – インタビューシリーズ

Tim Hudson は SSLeay の共同作者であり、2026年10月13日～15日にプラハで開催された OpenSSL Conference の主催者の一人です。システムとネットワークセキュリティの分野で30年以上の経験を持ち、OpenSSL Corporation の社長および Cryptsoft Pty Ltd の最高技術責任者を務めています。1995年以降、Eric Young と共同で SSLeay を創設し、後に OpenSSL Library へと発展した暗号ライブラリの共同創設、RSA Security Australia 開発センターの共同設立、米国暗号輸出規制の変更への貢献、30件以上の FIPS 140 認証の主導、OASIS KMIP および SAM 技術委員会の共同議長、RSA Conference、AusCERT、ICMC、LinuxConf、OpenSSL Conference などの主要セキュリティカンファレンスでの講演などを行ってきました。

OpenSSL は、世界で最も広く使用されている暗号ライブラリの一つである OpenSSL Library を開発・保守する、グローバルなオープンソース共同プロジェクトです。OS、クラウドプラットフォーム、エンタープライズソフトウェア、接続デバイス全般で利用され、毎日何十億もの安全なオンライン取引を保護しています。OpenSSL Foundation と OpenSSL Corporation を通じて、信頼できる暗号技術の推進、持続可能なオープンソース開発の支援、インターネットのセキュリティ強化に取り組んでいます。

You co-founded SSLeay with Eric Young in 1995 after recognizing the need for a non-US implementation of SSL, and that work ultimately became the foundation for OpenSSL. What problem were you originally trying to solve, and did you have any sense at the time that the technology could become such a fundamental part of securing the internet.

問題は非常に具体的で、まずは商業的な課題でした。当時私はブリスベンの Mincom に勤務しており、顧客から通信の保護を求められていましたが、購入できる手段がありませんでした。米国の暗号輸出規制により、米国製品は全く入手できないか、鍵長が極端に制限された状態で提供され、実装は事実上不可能でした。これは輸出方針への哲学的な反対ではなく、必要なコンポーネントが市場に存在しなかったというエンジニアリング上の問題でした。

私が持っていたのは、ほとんど忘れ去られていた知識でした。Eric Young は数年前に DES の実装を書いており、良質でクリーン、自由に利用できるコードでしたが、SSL とは無関係でした。Eric は SSL に関わっておらず、SSL の仕様が公開されたときに私がそれを読み、問題を持って彼に相談したところ、彼の既存の実装から比較的容易に拡張できると示しました。

しかしそれだけでは全体像は語れません。各パーツは単純でしたが、全体としては多数の要素が必要でした。DES の実装だけでは対称暗号が一つ得られるに過ぎません。SSL には公開鍵暗号、任意精度演算、ASN.1、X.509 証明書処理、プロトコル状態機械が必要で、すべてが正確でなければ暗号では「ほぼ正しい」ことと「破られた」ことは同義です。当初は楽観的に規模を見積もっていましたが、Eric はすぐにその規模を把握し、むしろ規模の大きさが障壁ではなく魅力であることに気付きました。別の形で始まることはなかったでしょう。

暗号コア部分は Eric が担当し、ライブラリに彼のイニシャルが付いたのもそのためです。私はライブラリを実際に展開できる形にするため、アプリケーション統合、テスト、ドキュメント、コミュニティ側を担当しました。また、競合する暗号ライブラリが使用されている場所を積極的に探し、置き換える作業も行いました。SSLtelnet、SSLftp、NCSA httpd など多数のパッケージは私の仕事で、Eric が実装した暗号アルゴリズムとプロトコル上に構築されたアプリケーションでした。この分担により、各自が本当に興味のある部分に集中でき、プロジェクトが継続した主な理由だと考えています。

オーストラリアに拠点があったことが解決の鍵となり、結果として多くの人が同じ課題を抱えていることが判明しました。ブリスベンで特定顧客向けに作られたものが、米国外のすべての人、そして最終的には米国内の多くの人にも有用となったのです。

それがどれほど大きくなるか予想していましたか？ いいえ。誰も重要インフラを作ろうとは思っていません。重要インフラとは、数年後に「誰がそれに依存しているか」を知ったときに初めて認識するものです。当時は目の前の課題を解決し、同じ壁にぶつかった他者からの質問に答えることが主な目的でしたが、質問に答えること自体がコードと同等に重要になったのです。

You have worked in cryptography and internet security for more than three decades. What has changed most dramatically about the threat landscape during that period, and which security problems have remained surprisingly similar despite enormous advances in technology?

最大の変化は、攻撃が職業化し、経済モデルが確立したことです。90年代半ばは、システム侵入は主に「面白い」から行われていましたが、現在は産業が形成され、専門化、ツール、サプライチェーン、顧客サポート、場合によっては国家資金まで存在します。これにより、好奇心ではなく、予算・期限・ビジネスケースを持った相手に対抗しなければならなくなりました。

二つ目は規模と依存関係です。1995 年の平均的なアプリケーションは自分で書くものでしたが、現在の平均的なアプリケーションは組み合わせであり、コードの大半は会ったことも名前も知らない人々が書いたものです。攻撃対象は自コードから依存ライブラリへと移り、多くの組織はまだこの認識に基づいた対策を取っていません。

一方で変わらない点は失敗パターンです。未検証の入力を解析するコードのバグ、見直されていないデフォルト設定、土曜日に失効する証明書、誤った場所に保存される認証情報、そして数学的に破られることの少ない暗号が設定ミスや無効化、未使用のままになることです。1996 年の上位 10 件の根本原因と先月のリストを比べても区別がつきません。技術は劇的に変わっても、ミスは変わらないのです。

OpenSSL 4.0 was released in 2026年4月, marking the project’s first major release in several years. What does this release tell us about where cryptographic infrastructure is heading, and which changes do you think will ultimately matter most to organizations that depend on OpenSSL?

4.0 で最も理解すべきことは、主に「削除」リリースであるという点です。これがリリースの目的でした。

ENGINE インターフェースを完全に削除し、SSLv3 と SSLv2 の ClientHello を削除、非推奨の楕円曲線と明示的 EC 曲線をコンパイル時に無効化、ASN1_STRING を不透明化し、多数の API シグネチャを厳格化しました。これらは開発者に作業を強いる変更であり、暗号ライブラリが機能追加だけでなく削除も行わなければ安全を保てないことを示しています。残したままの非推奨コードは、誰かが保守し続ける攻撃面となります。

追加機能としては、Encrypted Client Hello、RFC 8998 に基づくハイブリッド SM2/ML‑KEM グループ、cSHAKE、SNMP と SRTP の KDF、TLS 1.2 用の交渉型 FFDHE などがあります。特に ECH は、TLS 1.3 以降も Server Name Indication が訪問サイトの身元を漏らし続けていたという実質的なプライバシー欠陥を解消します。しかし、削除こそが本質です。

重要なポイントは次の通りです：4.0 は LTS リリースではありません。サポートは 2027 年 5 月までです。現在の長期安定版は 3.5 で、2030 年 4 月までサポートされ、すでにポスト量子アルゴリズムが含まれています。最新コードが欲しければ 4.0、安定した長期移行計画を立てたいなら 3.5 を選択すべきです。単に数字が大きいからという理由で選ぶのは誤りです。

Post-quantum cryptography has moved from a research problem toward a migration challenge, with OpenSSL already supporting ML-KEM, ML-DSA, and SLH-DSA and hybrid post-quantum key exchange. For business leaders who assume quantum computing is still too distant to worry about, what risks are they overlooking today?

最も一般的な誤りは「量子コンピュータが実用化される時期」を問うことです。正しい視点は「データをどれだけ長く機密に保つ必要があるか」と「移行にどれだけ時間がかかるか」です。後者を前者から引けば実際の期限が算出でき、多くの組織ではその期限はすでに過ぎています。

暗号化されたトラフィックは今日でも取得・無期限保存が可能です。もし情報の機密期限が 20 年（医療記録、従業員ファイル、知的財産、外交資料、財務情報など）であれば、攻撃者は現在量子コンピュータを必要とせず、将来的に入手できるだけのストレージと待機時間があれば十分です。これは推測的攻撃ではなく、実際のリスクです。

二つ目の見落としは、移行が単一プロジェクトではない点です。鍵交換は比較的容易で、既に多くが進行中です。OpenSSL 3.5 はハイブリッドポスト量子鍵交換を TLS のデフォルトにしたため、組織は意識せずにポスト量子鍵合意を利用しています。署名と証明書階層は難しく、証明書機関、ハードウェアトラストルート、ファームウェア署名鍵、15 年以上稼働するデバイスなどが RSA が永遠に有効と想定された設計に依存しています。

三つ目は予算化されていない制約です。ポスト量子署名はサイズが大きく、ML‑DSA‑65 の署名は ECDSA P‑256 の約 50 倍、SLH‑DSA はさらに大きくなります。これによりハンドシェイクサイズ、制約デバイス、フィールド長が固定されたプロトコル、衛星・IoT 回線などが問題になります。これらは標準を読むだけでなく、実際にテストしなければ分かりません。

One of the challenges with post-quantum migration is that organizations may not even know everywhere cryptography is being used across their applications, infrastructure, devices, and third-party dependencies. How should companies approach cryptographic inventory and crypto-agility so that the next major algorithm transition does not become an emergency?

まずは不快な事実を受け入れることです：ベンダーにアンケートを送っても暗号インベントリは作れません。返ってくるのはマーケティング文、正直な不確実性、数リリース前の情報です。ハードウェアベンダーのドキュメントを読んだ経験からも、記載と実際の機能差は想像以上に大きいです。

実際に見る必要があります。三層に分けて手法を変えます。自前コード：静的解析、依存スキャン、過去にハードコードしたアルゴリズム識別子の検索。リンクされたコード：ソフトウェア部品表（SBOM）を暗号部品表（CBOM）に拡張し、そこが CBOM の実用的な活用ポイントです。購入・接続したもの：ネットワーク観測。実際にワイヤ上で交渉される内容が真実であり、しばしば想定と異なります。

アジリティに関してはシンプルです：アルゴリズムはコード変更ではなく設定で切り替えられるべきです。暗号を変更するたびに開発者、ビルド、テスト、リリースが必要ならアジリティはありません。インターフェースを集中させ、変更箇所を一か所に限定します。

ほとんどの組織が飛び越えているステップは実践です。アジリティを実際に試すことです。静かな週末に非本番環境でアルゴリズムをオフにし、何が壊れるか確認します。必ず何かが壊れます。緊急移行時に驚くより、計画的に発見した方がはるかに安全です。

有効な強制手段の一つは証明書の有効期間です。業界は極端に短命な証明書へ移行しており、手動管理は不可能で自動化が必須になります。証明書の発行とローテーションを適切に自動化すれば、将来のアルゴリズム移行に必要な大半の仕組みが構築されたことになります。

AI is changing both cybersecurity defense and the capabilities available to attackers. Where do you believe AI genuinely changes the security equation, and where do you think organizations may be focusing too much on the technology while overlooking more fundamental weaknesses?

AI が実際に変えるのは「検出」側です。私たちの経験でも、今年 OpenSSL に報告された脆弱性の多くは AI 主導の解析で発見されました。1 月に 12 件の問題を修正したリリースは、すべて自動解析を行う研究グループからのパッチでした。6 月には AI システムと共同で作業していた研究者が見つけた PKCS#7 検証の高深刻度 use‑after‑free を修正しました。成熟した C コードのメモリ安全性やパーシングバグを自動解析で見つける能力は実際に変化しています。他の暗号ライブラリでも同様のパターンが見られます。

このことは両刃の剣です。同じ手法が攻撃者にも利用可能で、コードベースは同一です。防御側が独占的にアクセスできるわけではありません。

しかし、あまり語られない影響はメンテナの負担増です。見た目上の脆弱性レポートはほぼ無料で生成できますが、トリアージは人手が必要です。オープンソースのセキュリティチームは小規模でボランティアが多く、質のばらつく大量の報告に追われています。良質なものは再現コードとパッチが付随しますが、悪質なものはメンテナへのサービス拒否攻撃です。組織がオープンソースコードに対して AI を導入するなら、トリアージ能力への投資も忘れてはいけません。

AI が過大評価されがちな点は、システム自体を修正することです。AI はシステムをパッチ適用しません。資産インベントリを作成しません。資格情報をローテーションしません。サポート期限切れハードウェアを廃止しません。来月失効する証明書の責任者を指名しません。既知の未修正脆弱性を抱えたソフトウェアに AI セキュリティツールを導入しても、順序が間違っています。目立たない作業こそがリスクの本質です。

Many organizations invest heavily in tools but remain vulnerable because of configuration mistakes, outdated systems, weak processes, or poor incident preparation. What are the most consequential security mistakes you continue to see, and what should leadership teams have in place before an attack actually occurs?

最も致命的なミスは、セキュリティを調達活動とみなすことです。ツールは購入され、予算は消化され、ダッシュボードは緑色、しかし組織が根本的な対策を実行できるかどうかは誰も問いません。

二つ目は「自分が何を運用しているか」への無知です。存在しないソフトウェアはパッチできません。多くの組織はインシデント時に初めて資産の実態を把握します。これが部品表（BOM）作業が重要な理由で、コンプライアンスのためだけでなく、緊急時に「影響を受けるか」を即座に判断できる唯一の手段です。

三つ目はデフォルト設定です。システムは導入後にそのまま使用され、設定は見直されません。5 年後にはその設定が負債となり、当初の意思決定者はもう組織にいません。

四つ目は鍵と証明書の管理が個人に委ねられている点です。期限切れ証明書がスプレッドシートでひっそり管理され、担当者が異動したことで障害が発生するケースが多々あります。

インシデント前にリーダーシップが整えるべきは四つです。① 事前に書面で権限を明確にした、事業停止を決定できる指名された決定者。② 外部フォレンジックや専門顧問との契約（事前にサイン済み）。③ 侵害された可能性のあるシステムに依存しないコミュニケーションチャネル。④ エンドツーエンドでテスト済みの復旧能力（単なるバックアップの成功確認ではなく）。

そして定期的にリハーサルを行います。年に一度のエグゼクティブレベルのテーブルトップ演習は、追加ツールよりも実際のギャップを浮き彫りにします。

When a serious cyberattack does happen, executives can suddenly find themselves making technical, legal, operational, and communications decisions under enormous pressure. What separates organizations that respond effectively from those that allow an incident to become substantially worse?

効果的に対応できる組織は、インシデント前に重要な意思決定を済ませているため、インシデント時は実行に移すだけです。これが最大の違いです。

準備以外にも、以下の点が一貫して良い対応と悪い対応を分けます。

技術的調査と経営・広報のトラックを分離し、明確なインターフェースを設ける。侵入封じ込めと顧客通知の作業を同一人物が行うと、どちらも中途半端になります。

修復前に証拠を保存する。侵害されたマシンをすぐに再構築しようとすると、範囲特定に必要な情報が失われます。「他に何に触れたか」が答えられなければ、インシデントが終わったと信用できません。

初期情報は暫定的であることを受け入れ、適切に伝える。多くの評判被害は、ブリーチ自体ではなく、早期に出した自信過剰な声明を撤回せざるを得なくなったことから生じます。「現在分かっていること、まだ分からないこと、次回の更新時期」を伝えることは弱さではなく、逆転を防ぐ唯一の姿勢です。

そして最も重要なのは、エンジニアが経営陣に悪いニュースを伝えられる環境を作ることです。法的リスクが明らかで誰も実情を書きたがらない組織では、インシデントは沈黙の中で悪化します。エンジニアが自らの責任を負うのではなく、組織全体でガバナンスを確立すべきです。

OpenSSL sits in an unusual position as critical open-source infrastructure used throughout the technology ecosystem, while the OpenSSL Corporation focuses on serving commercial communities alongside the independently operated OpenSSL Foundation. How do you balance the needs of enterprises, developers, regulators, and the broader open-source community when decisions about security and compatibility can affect such a large portion of the internet?

正直な答えは、すべての決定で全員を満足させようとしないことです。公開されたポリシーを持ち、一貫して適用することで、結果に不満があっても予測可能性を提供します。

予測可能性はユーザーへの約束です。私たちは 4 月と 10 月に機能リリースを行い、どのリリースが長期安定版か、サポート期間はいつまでかを事前に告知します。重要な削除はリリース前に十分告知し、Corporation と Foundation の双方で合意しています。4 月に驚いたユーザーは注意を払っていなかっただけで、私たちは注意喚起をできる限り行いました。

構造的な答えは「分離」そのものです。Foundation はオープンソースライブラリとコミュニティを支援し、Corporation は商用要件（サポート契約、FIPS 認証、特定スケジュール）を持つ組織を支援し、財務的持続可能性を確保します。この二つを分けることで、どちらかのニーズが相手側に静かに犠牲になることはありません。企業要件とコミュニティ要件が衝突した場合でも、明確なミッションを持つ二つの組織間で議論が行われます。

もう一つは適切な聞き取りです。これは実際の仕組みが必要で、推測ではありません。だからこそ the conference を開催し、今年はプラハで開催します。メンテナがユーザーのニーズを推測するのは簡単ですが、実際に同じ部屋にいることで得られる情報は格段に価値があります。

Looking at the next decade, what security or cryptographic transition do you believe organizations are still underestimating today, and what lessons from the evolution of SSL, OpenSSL, and the past 30 years of internet security should leaders apply as they prepare for it?

過小評価されているのは、ポスト量子暗号そのものではなく、マシンアイデンティティと証明書階層です。

ポスト量子鍵交換はデフォルトでほぼ解決されつつありますが、信頼インフラ、すなわちハードウェアに埋め込まれたルート証明書、ファームウェア署名鍵、10 年以上稼働する HSM、2040 年まで稼働が見込まれる産業・医療システムは、製造時に暗号前提が組み込まれたままです。新しいライブラリを配布するだけでは更新できず、場合によっては更新不可能です。この置き換え規模は現在の資本計画に反映されていません。

それに伴う規制的移行もあります。欧州の Cyber Resilience Act や他地域の類似フレームワークは、組織が自ら書いていないコンポーネントを含むソフトウェアを出荷する際の義務を変えます。多くの組織はオープンソースへの依存やメンテナへの影響をまだ検討していません。

30 年の教訓は三つです：

1. 移行は公表された期間よりも 10 年長くかかる。SSLv3 は 2015 年に廃止が発表され、2016 年にデフォルトで無効化、2026 年 4 月にコードが削除されました。つまり 11 年かかりました。ポスト量子移行も同様に、プレスリリースではなく実際のスケジュールで計画すべきです。
2. デフォルトは唯一スケールできるセキュリティ制御。すべての管理者が正しい判断をする必要がある対策は実現しません。ハイブリッドポスト量子鍵交換が急速に普及したのは、デフォルトで有効化され、追加の判断が不要だったからです。ドキュメントを読む人はほとんどいないことを前提に設計すべきです。
3. 依存している人は自分が思うより少ない。地球上のほぼすべての組織は、極少数の個人がメンテナンスする暗号コードに依存しています。ブリスベンで二人が始めた当時と変わらず、ステークスが桁違いに高まっても構造は変わっていません。次の十年を計画するなら、連絡も資金も提供していないメンテナに依存している部分があることを認識すべきです。

Thank you for the great interview. Readers who wish to learn more should visit OpenSSL.