(57)【特許請求の範囲】
【請求項１】
送信者からのＶＮＦパッケージの受信に応答してＶＮＦイメージを含むＶＮＦパッケージの受信の承認を送るオーケストレーションユニットと、
ＶＮＦパッケージを格納し、さらに少なくともＶＮＦパッケージ署名のための証明書を生成するための秘密鍵を使って、ＶＮＦパッケージの証明書を生成する記憶ユニットと、
記憶ユニットからの要求に応答して秘密鍵を提供するＨＩＳＥＥ（Ｈａｒｄｗａｒｅ  Ｉｓｏｌａｔｅｄ  Ｓｅｃｕｒｅｄ  Ｅｘｅｃｕｔｉｏｎ  Ｅｎｖｉｒｏｎｍｅｎｔ）ユニットと、を含み、
前記オーケストレーションユニットは、記憶ユニットがＶＮＦパッケージ証明書の生成に成功した場合に、ＶＮＦパッケージの受信の承認を送ること、
を特徴とするＶＮＦパッケージ署名システム。
【請求項２】
ＨＩＳＥＥユニットが、ＨＩＳＥＥソフトウェアプラットフォームからの秘密鍵を読むセキュア環境エンジンを有する請求項１のＶＮＦパッケージ署名システム。
【請求項３】
セキュアな環境エンジンはアプリケーションプログラミングインターフェイス（ＡＰＩ）を提供し、秘密鍵要求を含むＡＰＩコールに応答して前記秘密鍵を返す請求項２のＶＮＦパッケージ署名システム。
【請求項４】
通常環境エンジンが、記憶ユニットとセキュア環境との間のメッセージを中継する請求項１から３いずれか一のＶＮＦパッケージ署名システム。
【請求項５】
記憶ユニットがＶＮＦパッケージ証明書生成に成功した場合に、オーケストレーションユニットがあらかじめ定められたＶＮＦカタログユニットに対して、ＶＮＦイメージ生成証明書を通知する請求項１から４いずれか一のＶＮＦパッケージ署名システム。
【請求項６】
記憶ユニットがＶＮＦパッケージ証明書生成に成功した場合に、オーケストレーションユニットがあらかじめ定められたＶＩＭ（ＶＮＦ  Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ  Ｍａｎａｇｅｒ）イメージリポジトリに、ＶＮＦイメージを格納する請求項１から５いずれか一のＶＮＦパッケージ署名システム。
【請求項７】
ＶＩＭ（ＶＮＦ  Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ  Ｍａｎａｇｅｒ）とＮＦＶＩ（Ｎｅｔｗｏｒｋ  Ｆｕｎｃｔｉｏｎ  Ｖｉｒｔｕａｌｉｚａｔｉｏｎ  Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）とをさらに含み、
前記ＶＮＦパッケージ署名システムはＶＮＦ署名機能を備えたＮＦＶ−ＭＡＮＯシステムとしても機能する請求項１から６いずれか一のＶＮＦパッケージ署名システム。
【請求項８】
オーケストレーション装置により、送信者からのＶＮＦパッケージの受信に応答して、ＶＮＦイメージを含むＶＮＦパッケージの受信の承認を送るステップと、
記憶装置により、ＶＮＦパッケージを格納し、そして、少なくともＶＮＦパッケージ署名の証明書を生成するための秘密鍵を使って、ＶＮＦパッケージの証明書を生成するステップと、
ＨＩＳＥＥ（Ｈａｒｄｗａｒｅ  Ｉｓｏｌａｔｅｄ  Ｓｅｃｕｒｅｄ  Ｅｘｅｃｕｔｉｏｎ  Ｅｎｖｉｒｏｎｍｅｎｔ）装置により、記憶装置からの要求に応答して前記秘密鍵を提供するステップと、を含み、
前記オーケストレーション装置は、記憶装置がＶＮＦパッケージ証明書生成に成功した場合に、受け取ったＶＮＦパッケージ承認を送ること、
を特徴とするＶＮＦパッケージ署名方法。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連出願についての記載）
本発明はインド特許出願：Ｎｏ．２０１７１１００４４３９（２０１７年２月７日出願）に基づくものであり、同出願の全記載内容は引用をもって本書に組み込み記載されているものとする。
本発明はＶＮＦ（仮想ネットワーク機能  Ｖｉｒｔｕａｌｉｚｅｄ  Ｎｅｔｗｏｒｋ  Ｆｕｎｃｔｉｏｎ）パッケージの署名システムと、ＶＮＦパッケージの署名方法に関する。
【背景技術】
【０００２】
ネットワーク機能仮想化（ＮＦＶ）は、先例のないスケールや複雑さや無統制な仮想環境に基づくセキュリティ問題や、柔軟性や、中央制御マネージメントに対して、ユニークな対処の機会をもたらす統一されたオーケストレーションプラットフォームである。
【０００３】
ミッションクリティカルなデータや不可欠なネットワーク機能をクラウドに移動させたいかどうか自らでも不確かな企業や信頼されるサードパーティーにとっては、ネットワークサービスやデータ保護がとりわけ重要であるため、ＮＦＶシステムではセキュリティが重要な問題である。
【０００４】
企業やサードパーティーのベンダーは、強制力のある保証がない場合、ＮＦＶシステムをベースとしたサービスを採用したがらない。従ってＮＦＶでは、機密データや各自のサービスのためのセキュリティ及び保護を、追加して提供する必要がある。
【０００５】
攻撃手法のうちいくつかを以下に示す。
・攻撃者が、コントロールプレーン及びベアラプレーンから機密を盗聴する。
・攻撃者が、インターフェイスあるいはネットワークの要素に過剰な量のデータを処理させることで、シグナリングプレーン及びデータプレーンの状態をサービス拒否状態 (ＤｏＳ) にする。
・攻撃者が、セキュリティのイメージやソフトウェアパッケージをねつ造する。
・サードパーティーベンダーあるいはユーザに対してフールプルーフを行う。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】欧州電気通信標準化機構（ＥＴＳＩ）「Ｎｅｔｗｏｒｋ  Ｆｕｎｃｔｉｏｎｓ  Ｖｉｒｔｕａｌｉｓａｔｉｏｎ（ＮＦＶ）；Ｍａｎａｇｅｍｅｎｔ  ａｎｄ  Ｏｒｃｈｅｓｔｒａｔｉｏｎ」，２０１７年２月７日検索），インターネット，＜URL: http://www.etsi.org/deliver/etsi_gs/NFV-MAN/001_099/001/01.01.01_60/gs_NFV-MAN001v010101p.pdf＞
【発明の概要】
【発明が解決しようとする課題】
【０００７】
図１３は、解決すべき問題を示す図である。図１４は、解決すべき問題を示す図である。
１）主な問題
全てのソフトウェアの署名は、仮想プラットフォーム実装（オンボーディング）前に検査しなければならない。
オペレータはサードパーティーから未署名のソフトウェアを受けとることがある。
オンボーディング前に標準的な検証方法が実施できるように、そのようなソフトウェアは（記憶域）格納前にセキュリティの観点による検証と署名を行うべきである。
本発明は、署名（時）の問題およびそのようなソフトウェアのセキュアな記憶（域）に関する問題に焦点を当てている。例えばこのような問題はＶＩＭ（Ｖｉｒｔｕａｌｉｚｅｄ  Ｉｎｆｒａｓｔｒａｃｔｕｒｅ  Ｍａｎａｇｅｒ）に対する最近のＰｒｉｍｅ  ａｎｄ  Ｐｒｏｂｅ  Ａｔｔａｃｋにおいて顕著であるからである。
【０００８】
２）その他の問題
ＭＡＮＯはセキュリティ証明（書）を格納する能力を有しない。
セキュアな記憶域から機密データが漏れることがある。
セキュアな記憶域はプラットフォームにある、いかなるＡＰＩ（アプリケーション・プログラミング・インターフェイス）からでもアクセス可能であるため、暗号証明書をセキュアな記憶域に格納したりセキュアな記憶域からアクセスできたりするとセキュア性が損なわれる。
【０００９】
３）関連する問題
ＶＮＦ採用を成功させる上で、ＶＮＦパッケージをオンボーディングしている過程で検証を行うという点が重要となる。
オンボーディングしている過程では、ＶＮＦパッケージの正当性が検証されていない。
ＶＮＦイメージに、数秒の間にマルウェアを感染させてしまう方法は何通りもありうる。
既存の手法では、内部攻撃者を潜在的な脅威として想定していない。
したがって、ＶＮＦのオンボーディングの間にＶＮＦを検証ないし認証する方法が求められている。
【課題を解決するための手段】
【００１０】
・ＭＡＮＯ（Ｍａｎａｇｅｍｅｎｔ  ａｎｄ  Ｏｒｃｈｅｓｔｒａｔｉｏｎ）は、セキュアな証明書を格納したりアクセスしたりするために必要な、セキュアな記憶域（ｓｔｏｒａｇｅ）やＨＩＳＥＥを扱う能力を有していない。
・本発明の解決手段を用いれば、ＶＮＦオンボーディング等のようなＭＡＮＯのいずれの機能についても、ＭＡＮＯとオペレータ／ＴＴＰ間でのセキュリティおよび信頼性がもたらされる。
・ＭＡＮＯ向けには二つのコンポーネントが提案される。すなわちセキュアな記憶域とＨＩＳＥＥである。
・ＭＡＮＯは、ＶＮＦパッケージをオンボーディングしている間に、そのイメージに対してオペレータもしくは信頼される第三者（ｔｒｕｓｔｅｄ  ｔｈｉｒｄ  ｐａｒｔｙ）が署名できる。
第一の視点に基づけば、次の要素を備えるＶＮＦパッケージ署名システムが提供される：
送信者からのＶＮＦパッケージの受信に応答してＶＮＦイメージを含むＶＮＦパッケージの受信の承認を送るオーケストレーションユニットと、ＶＮＦパッケージを格納しさらに少なくともＶＮＦパッケージ署名のための証明書を生成するための秘密鍵を用いてＶＮＦパッケージ証明書を生成する記憶ユニットと、記憶ユニットからの要求に応答して秘密鍵を提供するＨＩＳＥＥ（Ｈａｒｄｗａｒｅ  Ｉｓｏｌａｔｅｄ  Ｓｅｃｕｒｅｄ  Ｅｘｅｃｕｔｉｏｎ  Ｅｎｖｉｒｏｎｍｅｎｔ）。オーケストレーションユニットは、記憶ユニットがＶＮＦパッケージ証明書の生成に成功した場合に、ＶＮＦパッケージの受信の承認を送る。
第二の視点に基づけば、次のステップを含むＶＮＦパッケージ署名方法が提供される：
オーケストレーション装置により、送信者からのＶＮＦパッケージの受信に応答して、ＶＮＦイメージを含むＶＮＦパッケージの受信の承認を送るステップ、記憶装置により、ＶＮＦパッケージを格納し、そしてＶＮＦパッケージ証明書への署名を行うための秘密鍵を用いてＶＮＦパッケージの証明書を生成するステップ、ＨＩＳＥＥ（Ｈａｒｄｗａｒｅ  Ｉｓｏｌａｔｅｄ  Ｓｅｃｕｒｅｄ  Ｅｘｅｃｕｔｉｏｎ  Ｅｎｖｉｒｏｎｍｅｎｔ）装置により、記憶ユニットからの要求に応答して秘密鍵を提供するステップ。オーケストレーション装置は、記憶装置がＶＮＦパッケージ証明書の生成に成功した場合に、ＶＮＦパッケージの受信の承認を送る。
【発明の効果】
【００１１】
本発明がもたらす有利な効果の概要を以下に示す。
＜証明書マネージメント＞
・ＭＡＮＯは、オペレータもしくは信頼される（ｔｒｕｓｔｅｄ）サードパーティーがＶＮＦパッケージをオンボードする間にイメージに対してセキュアな署名を提供する。
・ＶＮＦパッケージに署名を行うため、ＭＡＮＯはＨＩＳＥＥから得た秘密鍵（Ｐｓ）の秘密なコンポーネントとモジュラス関数を用いてＶＮＦイメージを認証できる。
＜様々な目的のためのメッセージシーケンス＞
・ＶＮＦパッケージに署名するために与えられた秘密鍵（ＰＳ）からプライベートコンポーネントとモジュラス関数とを導出する。
・ＭＡＮＯにおいて、セキュアな記憶域とＨＩＳＥＥとのハンドシェイクを行う。
＜メッセージフォーマット＞
・ＭＡＮＯからセキュアな記憶域を介して、ＨＩＳＥＥに格納されている機密データにアクセスする。
・セキュアな記憶域とＨＩＳＥＥとの間で送られる、ＶＮＦイメージ署名要求のための手続き。
＜鍵生成＞
・ＮＦＶシステムにおいて認証や暗号化メカニズムのため要求される、ＭＡＮＯベースによるソフトウェア秘密鍵（ＰＳ）の生成
【図面の簡単な説明】
【００１２】
【図１】図１は、ＶＮＦパッケージをオンボーディングするシーケンス図を示すブロック図である。
【図２】図２は、ＶＮＦパッケージ署名時における送信者とＮＦＶＯとの間でのやりとりを示すブロック図である。
【図３】図３は、ＶＮＦパッケージ署名時における、セキュアな記憶域とＨＩＳＥＥとの間でのやりとりを示すブロック図である。
【図４】図４は、ＮＦＶシステムにオンボーディングする間に、ＶＮＦパッケージを署名するときのブロック図である。
【図５】図５は、オンボードＶＮＦパッケージの、署名処理シーケンスを示した図である。
【図６】図６は、オンボードＶＮＦパッケージの、署名処理の具体的なシーケンスを示した図である。
【図７】図７は、オンボードＶＮＦパッケージの、署名処理の具体的なシーケンスをメッセージフォーマットを用いて示した図である。
【図８】図８は、オンボードＶＮＦパッケージの、署名処理で用いられるテーブルメッセージフォーマットを示した表である。
【図９】図９は、オンボードＶＮＦパッケージの、本発明で提案された署名処理を要約した図である。
【図１０】図１０は、オンボードＶＮＦパッケージの、本発明で提案された署名処理の典型的な構造を示したブロック図である。
【図１１】図１１は、別のソリューションを説明した図である。
【図１２】図１２は、別のソリューションを説明した図である。
【図１３】図１３は、解決すべき問題を説明した図である。
【図１４】図１４は、解決すべき問題を説明した図である。
【発明を実施するための形態】
【００１３】
ＮＦＶシステムにおいてＶＮＦ署名を行う際のユースケース
（１）オンボーディングの間でのＶＮＦパッケージの署名
（１．１）導入部：ＶＮＦパッケージのオンボーディング
ＶＮＦパッケージのオンボーディングとは、カタログに含まれるべきＶＮＦパッケージをＮＦＶＯに移すプロセスを指す。図１はＶＮＦパッケージをオンボーディングする際のシーケンスダイアグラムを示している。ＶＮＦパッケージをオンボードし検証することが目的である。ＭＡＮＯに新たなＶＮＦがオンボーディングのため利用（入手）可能であることを知らせるプロセスについて以下に示す。
【００１４】
ａ）プロシジャー
１．送信者が新たなＶＮＦをアップロードし、さらにＮＦＶＯに対して新たなＶＮＦが利用可能になったことを通知する。
２．ＮＦＶＯが新たなＶＮＦのメタデータ（ＶＮＦ記述子）をリクエストする。
３．ＮＦＶＯにＶＮＦ記述子を与える。
４．ＮＦＶＯはＶＮＦＤを処理して、必須要素が与えられているかどうかチェックする。
５．ＮＦＶＯはＶＮＦカタログに対してＶＮＦＤをアップロードする。
【００１５】
（１．２） オンボーディングの間におけるＶＮＦパッケージの署名
ａ）問題点
ＶＮＦの採用の成功のために重要となるファクターは、ＶＮＦパッケージがオンボーディングされている最中に署名を行うことである。
オンボーディングされている間、ＶＮＦパッケージの正当性（ａｕｔｈｅｎｔｉｃｉｔｙ）は確証されることがない。
数秒の間にＶＮＦイメージに対してマルウェアを感染させる可能性の高い方法はいくつか存在する。
既知の手法は潜在的脅威として内部攻撃者（ｉｎｓｉｄｅｒ）を考慮していない。
従って、ＶＮＦがオンボーディングされている間に検証を行う必要がある。
【００１６】
ｂ）：記述
ＶＮＦパッケージをオンボーディングするとは、カタログ５００に含まれるべきＶＮＦパッケージをＮＦＶＯ２００に移すプロセスを指す。図４は証明書管理を使ってＶＮＦパッケージ署名を行う場合のブロック図を示している。ユースケースの目的は、我々の提案する仕組みを用いてＭＡＮＯ１０００により保護される信頼性と完全性を提供するべくＶＮＦパッケージの認証を行うものである。以下では任意の外部ユーザあるいは内部ユーザによるＶＮＦ署名手続きについて１ステップずつ説明している。このブロック図はＭＡＮＯコンポーネントで構成される。すなわち、ＨＩＳＥＥ（Ｈａｒｄｗａｒｅ  Ｉｓｏｌａｔｅｄ  Ｓｅｃｕｒｅｄ  Ｅｘｅｃｕｔｉｏｎ  Ｅｎｖｉｒｏｎｍｅｎｔ）４００、セキュアな環境エンジン（ＳＥＥ）４０１、通常環境エンジン８００、ＰＫＣコンテナ４０２、秘密鍵（ＰＳ）（ＨＩＳＥＥ  ＳＷ  Ｐｌａｔｆｏｒｍ；ＨＩＳＥＥ  Ｓｏｆｔｗａｒｅ  Ｐｌａｔｆｏｒｍ）４０３、秘密鍵（ＰＨ）（ＨＩＳＥＥ  ＨＷ  Ｐｌａｔｆｏｒｍ；ＨＩＳＥＥ  Ｈａｒｄｗａｒｅ  Ｐｌａｔｆｏｒｍ）、セキュアな記憶域３００とで構成されている。
【００１７】
セキュアな記憶域（ないし記憶装置）３００はユニークなキーで暗号化されたものがチェーン接続されており、証明書やライセンス、暗号化鍵データを格納する。セキュアな記憶域から他のデバイスへ生データを転送する行為はアクセスに失敗する。
【００１８】
ＨＩＳＥＥ（Ｈａｒｄｗａｒｅ  Ｉｓｏｌａｔｅｄ  Ｓｅｃｕｒｅｄ  Ｅｘｅｃｕｔｉｏｎ  Ｅｎｖｉｒｏｎｍｅｎｔ）４００は、ハードウェアにより強化されたセキュリティ環境であり、セキュリティ・サービスと、信頼できるチェーンとして他の要素とのインターフェイスの双方を提供する。ＨＩＳＥＥはセキュア環境エンジン（ＳＥＥ）と通常環境エンジン（ＮＥＥ）の二つのパラレル実行環境に分けられる。ＨＩＳＥＥはセキュア環境エンジン（ＳＥＥ）４０１と、公開鍵コンテナ（ＰＫＣ）４０２と、秘密鍵（ＰＳ）（ＨＩＳＥＥ  ＳＷＰｌａｔｆｏｒｍ）  ４０３と、秘密鍵（ＰＨ）（ＨＩＳＥＥ  ＨＷＰｌａｔｆｏｒｍ）４０４とで構成されている。ＮＦＶＯ２００の詳細な構成となっているＶＩＭとＮＦＶＩについては、ＥＴＳＩ  ＧＳ  ＮＦＶ  ＭＡＮ  ００１（ＮＰＬ１）の５．４．２節を参照。証明書署名を用いたＶＮＦパッケージのオンボーディングの段階ごとの説明は以下のサブセクションで示す。
【００１９】
ｃ）送信者とＮＦＶＯの間のやりとり
図２は、ＶＮＦパッケージ署名処理のうち、送信者とＮＦＶＯとの間のやりとりに関するブロック図である。
【００２０】
ｄ）セキュア記憶域とＨＩＳＥＥの間のやりとり
図３は、ＶＮＦパッケージ署名処理のうち、セキュア記憶域３００とＨＩＳＥＥ４００との間のやりとりに関するブロック図である。
【００２１】
ｉ．  通常環境エンジン（ＮＥＥ）８００は非セキュアな実行環境であり、通常環境エンジン８００からＨＩＳＥＥコンポーネントに要求を転送する。
ｉｉ．  セキュア環境エンジン（ＳＥＥ）は信頼可能（ｔｒｕｓｔｅｄ）であり、かつセキュアな記憶域３００からＳＥＥ４０１に対して要求を転送する証明可能なセキュア環境である。
ｉｉｉ．  ＰＫＣ（Ｐｕｂｌｉｃ−Ｋｅｙ  Ｃｒｙｐｔｏｇｒａｐｈｙ）コンテナ４０２は、秘密鍵（ＰＳ）（ＨＩＳＥＥ  ＳＷＰｌａｔｆｏｒｍ）４０３から公開エクスポーネント値とモジュラス値を抽出する。
ｉｖ．  秘密鍵（ＰＳ）（ＨＩＳＥＥ  ＳＷＰｌａｔｆｏｒｍ）は、ＨＩＳＥＥに格納されるソフトウェアベースの秘密鍵の一種である。
ｖ．  秘密鍵（ＰＨ）（ＨＩＳＥＥ  ＨＷＰｌａｔｆｏｒｍ）は、ＨＩＳＥＥに格納されるハードウェアベースの秘密鍵の一種である。
【００２２】
ｅ）ブロック図概観
図４は、ＮＦＶシステムにオンボーディングする間でのＶＮＦパッケージに署名を行う過程のブロック図を示している。
【００２３】
ｆ）ユースケース概観：ＶＮＦパッケージ署名の間におけるＨＩＳＥＥでの秘密鍵セキュア化方法
図５は、オンボードされたＶＮＦパッケージに署名をする手順を示している。
図６は、オンボードされたＶＮＦパッケージに署名をする具体的な手順を示している。
【００２４】
ｇ）プロシジャー
ステップ１：
ＶＮＦパッケージをオンボードするため、送信者１００からＮＦＶＯ２００にＶＮＦパッケージを送信する。
ステップ２：
ＮＦＶＯ２００は提案されたプロトコルを使って、ＶＮＦパッケージに署名する。
ステップ３：
ＶＮＦパッケージに署名するため、ＮＦＶＯ２００はセキュア記憶域３００に要求を転送する。
ステップ４：
セキュアな記憶域３００は、ＶＮＦ認証と、証明書生成に必要な秘密鍵（ＰＳ）のＡＰＩを開始する。
ステップ５：
秘密鍵（ＰＳ）のＡＰＩは秘密鍵（ＰＳ）を取得するために、通常の環境エンジン（ＮＥＥ）８００へコールを転送する。
ステップ６：
通常環境エンジン８００は、セキュアな環境に配置されているセキュアな環境エンジン（ＳＥＥ）４０１への要求をマッピングする。
ステップ７：
セキュアな環境エンジン（ＳＥＥ）４０１はＨＩＳＥＥに存在する秘密鍵（ＰＳ）を読み取る。
ステップ８：
セキュアな環境エンジン（ＳＥＥ）４０１は、認証要求があった場合その秘密のコンポーネント値を求め、その資格証明（ないし信頼性ｃｒｅｄｅｎｔｉａｌｓ）を通常環境エンジン（ＮＥＥ）８００に転送する。
ステップ９：
通常環境エンジン８００は、秘密鍵（ＰＳ）の秘密コンポーネント値を使って、セキュアな記憶域のＡＰＩコールに対して応答する。
ステップ１０：
セキュアな記憶域３００は証明書を生成し、秘密鍵（ＰＳ）の秘密コンポーネント値を使ってＶＮＦパッケージに署名を行い、秘密鍵（ＰＳ）の秘密コンポーネント値を永久に抹消する。
ステップ１１：
セキュアな記憶域３００はＮＦＶＯ２００に対して、証明書の生成とＶＮＦ署名の成功を承認する。
ステップ１２：
ＮＦＶＯ２００はカタログ５００に通知し、そしてＶＩＭ（Ｖｉｒｔｕａｌｉｚｅｄ  Ｉｎｆｒａｓｔｒａｃｔｕｒｅ  Ｍａｎａｇｅｒ）リポジトリにイメージのアップロードを通知する。
ステップ１３：
ＮＦＶＯ２００は送信者１００に対して、ＶＮＦパッケージのオンボーディングを承認する。
【００２５】
図７は、メッセージフォーマットを用いて、ＶＮＦパッケージをオンボーディングする際の具体的なシーケンスを示した図である。図８は、オンボードＶＮＦパッケージに署名する際に用いられるテーブルメッセージフォーマットを示した図である。
【００２６】
１．Ｏｎｂｏａｒｄ＿ＶＮＦＰａｃｋａｇｅ，Ｓｅｎｄｅｒ−＞ＮＦＶＯ
このメッセージは送信者１００からＮＦＶＯ２００に送られる、オンボードＶＮＦのイメージを定める。
２．Ｌｏｃａｔｅ＿Ｐｒｉｖａｔｅｋｅｙ（ＰＳ），ＮＦＶＯ−＞ＳＳ
このメッセージはＮＦＶＯ２００からセキュアな記憶域３００に送られる、ＮＦＶＯ２００が秘密鍵のＡＰＩをセキュアな記憶域３００に格納することを定める。
３．Ａｃｃｅｓｓ＿Ｐｒｉｖａｔｅ  ｋｅｙ（ＰＳ），ＳＳ−＞ＮＥＥ
このメッセージはＳＳ３００からＮＥＥ８００に送られる、秘密鍵の秘密コンポーネント値を要求するＡＰＩコールを転送することを定める。
４．Ａｃｃｅｓｓ＿Ｐｒｉｖａｔｅ  ｋｅｙ（ＰＳ），ＮＥＥ−＞ＳＥＥ
このメッセージはＮＥＥ８００からＳＥＥ４０１に送られる、秘密鍵の秘密コンポーネント値を要求するためのＡＰＩコールを転送することを定める。
５．Ｒｅａｄ＿Ｐｒｉｖａｔｅ  ｋｅｙ（ＰＳ），ＳＥＥ−＞ＨＩＳＥＥ
このメッセージはＳＥＥ４０１からＨＩＳＥＥ４０３／４０４に送られる、秘密鍵の秘密コンポーネント値を抽出することを定める。
６．Ｓｅｎｄ＿ＰｒｉｖａｔｅＶａｌｕｅ（ＰＳ），ＰＫＣＣｏｎｔ＜−ＨＩＳＥＥ(ＳＷ)
このメッセージはＨＩＳＥＥ（ＳＷ)４０３／４０４からＰＫＣコンテナ４０２に送り、ＰＫＣコンテナ４０２に秘密鍵の秘密コンポーネント値を格納することを定める。
７．Ｆｏｒｍｕｌａｔｅ＿ＰｒｉｖａｔｅＶａｌｕｅｓ，ＰＫＣＣｏｎｔ
このメッセージは、ＰＫＣコンテナ４０２において秘密コンポーネント値を作成することを定める。
８．Ｓｅｎｄ＿ＰｒｉｖａｔｅＶａｌｕｅｓ，ＳＥＥ＜−ＰＫＣＣｏｎｔ
このメッセージはＰＫＣコンテナ４０２からＳＥＥ４０１に、秘密鍵の秘密コンポーネント値を転送することを定める。
９．Ｒｅｓｐｏｎｓｅ＿Ｐｒｉｖａｔｅ  ｋｅｙ（ＰＳ），ＮＥＥ＜−ＳＥＥ
このメッセージはＳＥＥ４０１からＮＥＥ８００に、秘密鍵の秘密コンポーネント値を転送することを定める。
１０．Ｒｅｓｐｏｎｓｅ＿Ｐｒｉｖａｔｅ  ｋｅｙ（ＰＳ），ＳＳ＜−ＮＥＥ
このメッセージはＮＥＥ８００からセキュアな記憶域３００に、秘密鍵の秘密コンポーネント値を転送することを定める。
１１．ＳＳ＿ＣｅｒｔｉｆｉｃａｔｅＧｅｎ＿ＶＮＦ，ＳＳ
このメッセージは、秘密鍵の秘密コンポーネント値を用いて、セキュアな記憶域３００におけるＶＮＦ証明書の生成や署名を定める。
１２．Ｒｅｓｐｏｎｓｅ＿ＶＮＦ＿Ｃｅｒｔｉｆｉｃａｔｉｏｎ＿Ｓｉｇｎｉｎｇ＿ｓｔａｔｕｓ，ＮＦＶＯ＜−ＳＳ
このメッセージはセキュアな記憶域（ＳＳ）３００からＮＦＶＯ２００に送られる、ＶＮＦ証明書の生成および署名のステータスを定める。
１３．Ｎｏｔｉｆｙ＿Ｃａｔａｌｏｇ，ＮＦＶＯ−＞Ｃａｔａｌｏｇ
このメッセージはＮＦＶＯ２００からカタログ５００に送られる、証明書の生成および署名のステータスを定める。
１４．Ｕｐｌｏａｄ＿Ｉｍａｇｅｓ，ＮＦＶＯ−＞ＶＩＭＲＥＰＯ
このメッセージはＮＦＶＯ２００からＶＩＭリポジトリ６００に送られる、ＶＮＦイメージのアップロードステータスを定める。
１５．Ａｃｋ＿Ｉｍａｇｅ＿ｕｐｌｏａｄ，ＮＦＶＯ＜−ＶＩＭＲＥＰＯ
このメッセージはＶＩＭリポジトリ６００からＮＦＶＯ２００に送られる、ＶＮＦイメージアップロードの承認ステータスを定める。
１６．Ａｃｋ＿Ｏｎ−Ｂｏａｒｄ＿ＶＮＦＰａｃｋａｇｅ，Ｓｅｎｄｅｒ＜−ＮＦＶＯ
このメッセージはＮＦＶＯ２００から送信者１００に送られる、オンボーディングするＶＮＦイメージの承認ステータスを定める。
【００２７】
図９は、本発明による、オンボードするＶＮＦパッケージへの署名の概要を示す図である。
【００２８】
図１０は、本発明による、オンボードＶＮＦパッケージへの署名処理に関する典型的なアーキテクチャを示すブロック図である。
ハイライトされているセキュアな記憶域３００とＨＩＳＥＥ４００とがＮＦＶ  ＭＡＮＯの典型的なアーキテクチャとして加わっている。さらに、リファレンスポイント「Ｏｒ−Ｍｓｓ」「Ｍｓｓ−Ｍｈａ」としてインターフェイスが加わっている。図左側にあるＮＦＶＩの枠には、セキュアな環境エンジン４０１とＰＫＣコンテナ４０２と、秘密鍵（ＰＳ）（ＨＩＳＥＥ  ＳＷＰｌａｔｆｏｒｍ）４０３と、通常環境エンジン８００とが、ＶＩＭ（Ｖｉｒｔｕａｌｉｚｅｄ  Ｉｎｆｒａｓｔｒａｃｔｕｒｅ  Ｍａｎａｇｅｒ（ｓ））９６０により仮想レイヤにおいて実現することができる。一方秘密鍵（ＰＨ）（ＨＩＳＥＥ  ＨＷ  Ｐｌａｔｆｏｒｍ）４０４に対応する元の秘密鍵（ＰＨ）は、ハードウェアリソースとして隔離して配置されている。
【００２９】
上述したモードでは、以下の仮定を前提としている。
・証明書の秘密鍵は、証明書が生成されている間ＨＩＳＥＥ４００にセキュアに格納されている。
・送信者１００は、ＮＦストアとして参照されることができる。
・ＶＮＦ署名および証明書生成は、ＶＮＦパッケージのアップロードの間に、実行される
【００３０】
本発明の推奨形態と比較した場合のソリューションを以下に述べる（図１１及び図１２参照）。
表題１：暗号化によるロール認証を用いた封印（シール）、デジタルスタンプ、及び署名としての使用のためのシステムあるいは方法
・このロール認証には関連するポリシーがあり、暗号化を行う場合とデジタル署名を行う場合の双方で利用できる。
・グループに属する各個人は、同じロール証明書を共に持ち、グループを代表して署名を行える。
・グループに属する各個人は、ロール証明を用いて暗号化された、グループ宛てもしくはグループ内のメンバーへのメッセージを復号できる。
・鍵復元権限は、期限切れとなったロール証明の鍵の回復に利用される。
【００３１】
表題２：異種混在環境における証明書ベースの認証システム
・コンソールのオペレータが、代表的コンピュータもしくは「コア」に一度ログインするだけで、様々なコンピュータが混在（ｈｅｔｅｒｏｇｅｎｅｏｕｓ）しているシステムに対する認証をする方法および装置。
・ログイン完了後、オペレータがセッション証明書を取得し、そのオペレータが自らのＩＤおよび所属グループに関する情報などを、他のノードやネットワークで証明可能にする。
・セッション証明書署名前に、証明書内拡張データエリアにデータを埋め込む。
・ユーザ名や、グループ所属や、コアコンピュータやネットワーク内にある他のデバイスの名前空間に基づく拡張データは、その名前空間に属していなくてもあるいは同じネットワークＯＳを使っていない場合でさえも利用可能である。
・管理可能なデバイスは、セッション証明書保有者から送信された拡張データに基づいて、自分自身へのアクセスの認証及び承認が可能。
・証明書の信頼性と所有権は、標準の公開鍵暗号化方法を使用して検証する。
【００３２】
上で述べた通り、本実施形態によればＶＮＦ使用のためのセキュアな環境を提供することが可能である。
【００３３】
上述の説明で本発明の実施形態を説明したが、本開示は上で述べたそれぞれの実施形態に限定されることなく、様々な修正、置換、調節が可能である。さらに本開示はそれぞれの実施形態を任意に組み合わせてもよい。すなわち本開示は請求の範囲全体及びその技術的思想に基づいた当業者が想定可能な様々な種類の変形、変更、修正を含む。
【００３４】
例えば上述の実施形態では「ＨＩＳＥＥ」という用語を用いているが、「ＨＭＥＥ（Ｈａｒｄｗａｒｅ  Ｍｅｄｉａｔｅｄ  Ｓｅｃｕｒｅ  Ｅｎｃｌａｖｅｓ：ＮＦＶ−ＳＥＣ０１２  Ｖ３．１．１参照）」など「ＨＩＳＥＥ」と同等の方式が本発明で適用可能である。
【００３５】
上記非特許文献の全記載内容は引用をもって本書に組み込み記載されているものとする。実施形態および実施例については、特許請求の範囲を含む本発明による全開示の範囲内において、またその基本的な技術的思想に基づいて変更及び調整が可能である。また、本発明の請求項の範囲内において、請求の範囲の各要素や実施形態や実施例の各要素や各図面の各要素などの多様な組み合わせ及び選択が可能である。すなわち本発明は特許請求の範囲を含む全開示内容及び技術的思想に基づいて当業者が実施可能なあらゆる変形およびあらゆる変更（バリエーション）を含むものと理解されるべきである。
【符号の説明】
【００３６】
１００  送信者
１００ａ  ＯＳＳ／ＢＳＳ
１００ｂ  外部送信者
２００  ＮＦＶＯ
２００ａ  オーケストレータ
３００  セキュアな記憶域（ＳＳ）（ないし記憶装置）
４００  ＨＩＳＥＥ
４０１  セキュアな環境エンジン（ＳＥＥ）
４０２  ＰＫＣコンテナ（Ｐｕｂｌｉｃ−Ｋｅｙ  Ｃｒｙｐｔｏｇｒａｐｈｙコンテナ）
４０３  秘密鍵（ＰＳ）（ＨＩＳＥＥ  ＳＷプラットフォーム）
４０４  秘密鍵（ＰＨ）（ＨＩＳＥＥ  ＨＷプラットフォーム）
５００  カタログ
６００  ＶＩＭイメージリポジトリ
８００  通常環境エンジン（ＮＥＥ）
９５０  ＶＮＦマネージャ
９６０  仮想インフラストラクチャマネージャ（ＶＩＭ）
９７０  ＮＦＶＩ
１０００  （ＮＦＶ）ＭＡＮＯ
【図１】
0006806263.tif 000002
【図２】
0006806263.tif 000003
【図３】
0006806263.tif 000004
【図４】
0006806263.tif 000005
【図５】
0006806263.tif 000006
【図６】
0006806263.tif 000007
【図７】
0006806263.tif 000008
【図８】
0006806263.tif 000009
【図９】
0006806263.tif 000010
【図１０】
0006806263.tif 000011
【図１１】
0006806263.tif 000012
【図１２】
0006806263.tif 000013
【図１３】
0006806263.tif 000014
【図１４】
0006806263.tif 000015