開発した

サプライチェーンセキュリティに寄与するコードがOpenSSLにマージされました!

ishigaki

属性証明書の実装がOpenSSLに取り込まれたことで、サプライチェーンセキュリティにどのような影響を与えるのかを詳しく解説していきます。

はじめに

現代のICTにおいて、サプライチェーンは、トレーサビリティの確保、セキュリティの強化、複雑な調達プロセスの管理など、多くの技術的挑戦に直面しています。特に、サプライチェーンセキュリティの観点から、トレーサビリティ、つまりその製品がいつ、どこで、だれによって作られたのかを明確にすることが大きな課題となっています。 昨年、アメリカ国家安全保障局1からサプライチェーンに関するガイダンスが示されました。このガイダンスでは、トレーサビリティを確立する方法として、Trusted Computing Group2が策定したPlatform Certificate3規格を利用することが示されています。Platform Certificateは、Internet Engineering Task Force4が標準化を進めた属性証明書のデータフォーマット規格であるRFC 5755に基づいており、製造者やコンポーネントの構成を証明することができます。

しかしながら、2020年頃はPlatform Certificateおよび属性証明書の規格に対応するソフトウェアは限られていました。当時において対応するソフトウェアは、Javaベースでありメモリーの制約やJVMをインストールすることが必要となるなど様々な環境への導入が課題となりました。一方、OpenSSL5は様々な環境に組み込まれていましたが、属性証明書の規格には対応していませんでした。もしOpenSSLが属性証明書の規格に対応すれば、様々な環境で利用可能となり、結果的にPlatform Certificateの検証が容易になり、サプライチェーンセキュリティの向上に繋がるだろうと考えていました。

そこで2021年にOpenSSLへのRFC 5755の実装を寄贈し、様々なレビュープロセスを得て先日ようやく取り込まれました。これにより、様々な環境でPlatform Certificateが利用できるようになり、サプライチェーンセキュリティの課題解決に向けた基盤が整ったといえます。

本記事では、RFC 5755の実装がOpenSSLに取り込まれたことで、サプライチェーンセキュリティにどのような影響を与えるのかを詳しく解説していきます。

今回OpenSSLに取り込まれた実装は、弊社とイーゲル社6が協働でOpenSSLへ寄贈を行い、約三年の期間を要し最終的にOpenSSLに統合されました。改めて、イーゲル社のDamianさん、端山さん、およびTCGのメンバーの方々に感謝申し上げます。

取り込まれたコードはOpenSSL v3.4.0として2024年10月14日にリリースされる予定となっています。

今後、世の中の何億台ともあるデバイスに導入が進むことが考えられ、大きな期待を感じます。

RFC 5755とは？

RFC 5755は属性証明書のデータフォーマット規格です。属性証明書は、X.5097の公開鍵証明書とは異なるデータフォーマットを持ち、主な違いは属性証明書には公開鍵が含まれないことです。X.509の公開鍵証明書がアイデンティティと公開鍵を結合することを目的としているのに対し、属性証明書は、X.509の公開鍵証明書に関連付けられた属性情報を証明することを目的としています。

RFC5755のIntroductionでは、属性証明書の目的について以下のように説明されています（意訳）

X.509公開鍵証明書（PKC）は、アイデンティティと公開鍵を結合します。属性証明書（AC）は、PKCと似た構造を持ちますが、主な違いはACには公開鍵が含まれないことです。ACには、AC所有者に関連付けられたグループメンバーシップ、役割、セキュリティクリアランス、またはその他の認証情報を指定する属性が含まれる場合があります。

ACの構文はX.509勧告で定義されているため、「X.509証明書」という用語は曖昧になっています。 一部の人々は、PKCとACを常に混同しています。たとえを用いることで違いが明確になるかもしれません。PKCはパスポートのようなものと考えることができます。所有者を識別し、長期間有効であり、簡単に取得できるものではありません。ACは入国ビザに似ています。通常、別の機関によって発行され、有効期間はそれほど長くありません。入国ビザの取得には通常パスポートの提示が必要であるため、ビザの取得プロセスは比較的シンプルになることがあります。

認証情報は、PKC拡張に配置することも、別の属性証明書（AC）に配置することもできます。PKC内の認証情報の配置は、通常、2つの理由から望ましくありません。第一に、認証情報は、多くの場合、アイデンティティと公開鍵の結合と同じ有効期間を持っていません。認証情報がPKC拡張に配置されている場合、一般的な結果として、PKCの有効期間が短縮されます。第二に、PKC発行者は通常、認証情報に対する権限を持っていません。これにより、PKC発行者が権限のある情報源から認証情報を取得するための追加の手順が発生します。

これらの理由から、認証情報をPKCから分離する方が良いことがよくあります。しかし、認証情報もアイデンティティに結び付ける必要があります。ACはこの結合を提供します。それは単にデジタル署名（または認証された）アイデンティティと属性のセットです。

ACは、アクセス制御、データ発信元認証、否認防止など、さまざまなセキュリティサービスで使用できます。

PKCは、アクセス制御の意思決定機能にアイデンティティを提供できます。ただし、多くの状況では、アクセス制御の決定に使用される基準はアイデンティティではなく、アクセス要求者の役割またはグループメンバーシップです。このようなアクセス制御方式は、役割ベースのアクセス制御と呼ばれます。

ACに基づいてアクセス制御の決定を行う場合、アクセス制御決定機能は、適切なAC所有者がアクセスを要求したエンティティであることを確認する必要がある場合があります。要求またはアイデンティティとACの間のリンクを実現する1つの方法は、AC内にPKCへの参照を含めることと、アクセス要求内の認証にPKCに対応する秘密鍵を使用することです。

ACは、データ発信元認証サービスと否認防止サービスのコンテキストでも使用できます。これらのコンテキストでは、ACに含まれる属性は、署名エンティティに関する追加情報を提供します。この情報は、エンティティがデータに署名する権限があることを確認するために使用できます。この種のチェックは、データが交換されるコンテキストまたはデジタル署名されたデータのいずれかに依存します。

注意:公的個人認証サービス利用のための民間事業者向けガイドラインでは 民間事業者が利用者証明用電子証明書を利用する場合には、利用者ごとの「利用者識別情報」と「利用者証明用電子証明書」を紐付ける必要がある。そのための方法として、同一個人宛てに発行された「署名用電子証明書の発行番号（「シリアル番号」のことをいう。以下同様。）」を基に「利用者証明用電子証明書の発行番号」を機構に照会する方法が有効と考えられる。 「署名用電子証明書」には基本４情報が記録されているため、それを基に、「利用者識別情報と署名用電子証明書を紐付ける」ことが可能である。また機構は、署名用電子証明書の発行番号を基に「利用者証明用電子証明書の発行番号」を応答する機能を保有しているため、民間事業者は、署名検証機能にて取得した「署名用電子証明書の発行番号」を機構に送信することで、 「利用者証明用電子証明書の発行番号」の取得が可能となる。この場合の紐付け方法の全体イメージを図 4-3 に、民間事業者と機構における本機能を使用した紐付け処理の流れを図 4-4 に示す。 なお、署名用電子証明書及び利用者証明用電子証明書の発行番号については、電子署名等確認業務以外の業務において、個人を識別し管理するための符号として直接に使用してはならず、また、外部に提供してはならない。 と記載があり法令に基づいて情報を扱う必要があります。

上記の説明ではパスポートを例にして属性証明書の目的や利用状況を説明していますが、実際の応用例として、マイナンバーカードを使ってウェブサイトへのmTLS認証を行う際に、属性証明書を用いることで、X.509公開鍵証明書には含まれない属性情報を付与し、きめ細やかな認可制御を行うことが技術的に可能となります。

マイナンバーカードの認証向けX509の公開鍵証明書(利用者証明用電子証明書)にはemailや氏名などの個人情報といった属性情報(利用者証明用電子証明書には、基本４情報が記録されていないため、単体ではその電子証明書が誰に紐付くものであるかを判別することができない。)がないため、認証を行うアプリケーションでは証明書のシリアル番号から主体を判定する必要があります。

従って認証を行うアプリケーションでは証明書のシリアル番号のみで認可する内容を決定する必要が有り、属性に応じた細かな権限管理を行いたい場合、大変扱いにくいこととなります。

そこで属性証明書を利用すると、このような課題が解決できます。仕組みとしてはX509の公開鍵証明書にリンクを行った属性証明書を生成し、その属性証明書にemailや所属、ロール等を属性情報記述し、サーバ側は属性証明書に記載された属性情報に基づき、認可の管理や代理認証など様々な動作を行わせる事が可能になります。またクライアント側公開鍵証明書には変更が必要ではありませんので相互性の問題を気にする必要がありません。

属性証明書の詳しい仕組みを知りたいかたは是非RFC 5755やITUのX.509 Information technology – Open Systems Interconnection – The Directory: Public-key and attribute certificate frameworksを読んで見てください。

上記の意訳のところでも記載されていますが、X.509の公開鍵証明書と属性証明書を混同している人、属性証明書をX509の公開鍵証明書と同じように説明し誤解を与える解説がありますが、RFC 5755を読んでみるとX509のASN.1定義と属性証明書のASN.1定義が同じではないと理解できるかと思います。

Platform Certificateとは?

Platform Certificateは、これまで説明してきたRFC 5755準拠の属性証明書の1カテゴリであり、Platform Certfificateは、デバイス、ソフトウエアの構成を証明するために使用される証明書で、ハードウェアとソフトウェアの完全性が検証可能となります。RFC 5755の実装がOpenSSLに組み込まれることは、属性証明書の一種であるPlatform Certificateの対応にもつながり、最終的にサプライチェーンセキュリティの向上に寄与します。つまりスーパーで野菜を購入する際に生産者の顔写真がついていて、QRコードを読むといつどこで生産されたか把握できる食品のトレーサビリティと同じような仕組みが実現可能となります。

今回OpenSSLへ寄贈したRFC 5755の実装には、属性証明書の解析、検証、生成機能、および失効管理機能が含まれています。この機能を利用することで、様々な環境で属性証明書を用いたアプリケーション開発が可能になります。属性証明書を活用することで、きめ細やかなアクセス制御(認可管理)であったり、トレーサビリティの確保によるサプライチェーンセキュリティの向上に大きく寄与することが可能です。

実装にはコマンドラインインタフェースはないためAPIを利用した開発が必要です。

詳細な実装内容はGitHubのプルリクエスト #15857に記載されているので興味があればご覧下さい。

サプライチェーン全体の信頼性を向上

製品出荷者がPlatform Certificateをサーバ、デスクトップ、ラップトップ、CPUボード等の機器に組み込み、購入者または利用者は機器内部に存在するPlatform Certificateの検証を行うことによって、以下のような脅威を軽減し、サプライチェーン全体の信頼性が向上します。

  • ハードウェアの変更(Hardware Bill of Material: HBOM)
  • ファームウェア情報の偽造や改ざん(Software Bill of Material: SBOM)

また、「機器調達者やOEM先等が、機器の構成を変更したりOSやソフトウエアのインストールを行う。」等のカスタマイズを行うケースでも差分を記載したDelta Platform Certificateを発行し機器に組み込む事で、変更履歴としてトレーサビリティを確保することができます。

Platform CertificateにSBOMの一つであるTCG Reference Integrity Manifest8を参照させることも可能となるためOSやアプリケーションの改ざん9等、検証が可能となります。

したがって、機器の利用者、もしくはシステム管理者はPlatform Certificateを用いてデバイスの製造元や販売元を確実に検証することで、模倣品や不正なデバイス、ファームウェア、ソフトウェアの混入を検出することができます。

過去2020年にTCGメンバーのComputer Systems Researcher, National Security AgencyのLawrence Reinert氏とPrincipal Engineer, Cybersecurity, GE ResearchのMonty Wiseman氏が行ったセッションにおいてサプライチェーンセキュリティ強化方法について説明された動画が公開されていますので興味があるかたはご覧下さい。

https://www.rsaconference.com/Library/presentation/USA/2020/industry-standards-to-support-supply-chain-risk-management-for-firmware

併せて過去に掲載したNSAのサプライチェーンリスク管理の記事では、信頼できるハードウェアとソフトウェアの検証が極めて重要であることを解説していますのでこちらもご覧ください。

おわりに

OpenSSLにおけるRFC 5755のサポートは、技術的なセキュリティ強化だけでなく、トレーサビリティの解決に寄与する重要なステップとなります。今後導入が広がることで、サプライチェーン全体の信頼性が向上し、不正なデバイスやソフトウェアの混入などの脅威の軽減に繋がります。

今回、弊社とイーゲル社で協働開発したRFC 5755の実装が、OpenSSLを通じて広く利用されることで、サプライチェーンセキュリティの強化に貢献できることを嬉しく思います。今後もこのような取り組みを継続し、より安全なデジタル環境の実現に寄与できるように活動を続けたいと考えています。

TCG Platform Certificateに対応した商用認証局

弊社は、世界で最初にTCG Platform Certificateをサポートする商用認証局をリリースしました。TCGのウェブページでも紹介がされています。 https://trustedcomputinggroup.org/worlds-first-commercial-certification-authority-supporting-the-issuance-of-platform-certificates/

防衛業界、医療業界、金融業界、政府などサプライチェーンのセキュリティ要求が高い業界、業種において様々なユースケースに対応可能な商用認証局として活用いただくことが可能です。

ユースケース:

導入事例:

NECのIAサーバ「Express5800シリーズ」に適用され、今後、NECの各種ICT機器に順次適応される予定となっています。 詳しくは下記のニュースリリースを参照下さい。 https://jpn.nec.com/press/202403/20240304_01.html

詳細内容や、技術的な相談等についてお問合せフォームからご相談ください。

  1. 通称NSA。アメリカ国防総省の情報機関 ↩︎

  2. 略称TCG。コンピュータ機器の信頼性と安全性を高める国際業界標準規格を制定する業界団体 ↩︎

  3. TCGが規格化したデバイスの構成証明書 ↩︎

  4. 略称IETF。インターネットで利用される各種技術の標準化を推進している国際任意団体。 ↩︎

  5. OpenSSLは、コンピューターネットワーク上の安全な通信を提供し、通信相手を識別するアプリケーション向けのソフトウェアライブラリです。インターネットサーバーで広く使用されており、HTTPSウェブサイトの大部分にも利用されています。 ↩︎

  6. 株式会社イーゲル ↩︎

  7. X.509の公開鍵証明書は、HTTPSの基盤であるTLS/SSLなど、多くのインターネットプロトコルで使用されています。これはウェブを安全に閲覧するために使用されています。また、電子署名のようなオフラインアプリケーションでも使用されています。 ↩︎

  8. SWIDタグ(ISO/IEC 19770-2)のデータフォーマットをベースとし、TCGが規格化したSBOM ↩︎

  9. Linux IMAを利用することでOSやアプリケーション、ファイル等の完全性を担保することが可能 ↩︎

© 2016 - 2024 DARK MATTER / Built with Hugo / Theme Stack designed by Jimmy