4.4.2 セキュリティに関する注意事項
- 〈この項の構成〉
(1) XML署名構文に記述する情報
XML署名では,XML署名構文の中に記述される情報を基に,セキュリティを確保します。XML署名アプリケーションは,XML署名構文に記述された情報の内容が正しいことを確認する必要があります。そのため,XML署名アプリケーションを開発する場合,署名対象と指定するアルゴリズムを意識する必要があります。署名対象と指定するアルゴリズムについての注意事項を説明します。
(a) 署名対象
署名対象は,Reference要素のURI属性と変換処理に基づいて決定します。XML署名アプリケーションを開発する場合,署名対象としたいデータを正しく取得できるようにReference要素のURI属性と変換処理を指定してください。署名対象に関する注意事項を次に示します。
-
Reference要素に指定されている情報についての注意事項
検証側が意図しない個所に署名が付与されている場合,検証が成功しても,データの完全性が保証されないことがあります。署名を検証するときは,指定された署名対象が,検証に使用するXML署名アプリケーションにとって有効な指定であることを必ず確認してください。
例えば,明細書データのクレジットカード番号の部分に付与された署名を検証する場合は,クレジットカード番号が署名対象となっていることを確認する必要があります。クレジットカード番号以外の部分が署名対象となっていた場合,クレジットカード番号が改ざんされていたとしても,署名検証によって改ざんを検知することはできません。
-
XML署名アプリケーションは,署名対象とするデータをキャッシュする場合がありますが,XML署名エンジンは,署名対象データからダイジェスト値を計算するだけです。キャッシュされた署名対象データが最新の署名対象データと同じかどうかは確認しないので,注意してください。
-
XML署名の署名対象となるデータは,変換処理の結果から得られるデータだけです。変換処理で失われた情報は保証されないので,注意してください。例えば,コメントを除く正規化の変換処理を指定した場合,コメントの情報は保証されません。
-
XML署名は参照先のデータまでは保証しないため,署名対象データの中で,ほかのデータを参照する場合は注意する必要があります。参照先のデータをXML署名によって保証したいときは,参照先のデータも明示的に署名対象とする必要があります。例えば,HTMLデータで<img>タグによって参照している画像データを保証したい場合は,HTMLデータだけでなく画像データも署名対象とします。
(2) セキュリティモデルの選択
XML署名仕様およびXML暗号仕様では,公開鍵署名などの公開鍵ベースのセキュリティや,鍵ハッシュ認証コードまたは共通鍵暗号などの共通鍵ベースのセキュリティなど,さまざまなセキュリティモデルを適用できます。ただし,XML署名仕様およびXML暗号仕様ではセキュリティモデルの信頼性や利便性については言及していません。そのため,XML署名アプリケーションまたはXML暗号アプリケーションを開発する場合は,アプリケーションの用途に応じて適切なセキュリティモデルを選択する必要があります。
(3) セキュリティの強度
XML署名またはXML暗号のセキュリティの強度は,署名アルゴリズム,暗号アルゴリズム,ダイジェストアルゴリズム,鍵生成の強度,鍵のサイズ,鍵または証明書認証のセキュリティ,鍵配布の仕組みなどに依存します。XML署名アプリケーションまたはXML暗号アプリケーションを開発する場合は,開発に必要なXML署名ライブラリの機能,および認証基盤となるPKIや暗号エンジンのライブラリの信頼性を考慮して,開発に使用するライブラリを選択するようにしてください。
なお,操作手順やシステムの運用に関係するユーザーの完全性,またはシステム管理を実行する上での強制力なども,システム全体のセキュリティ強度に影響します。システムを設計する場合は,これらの要素も考慮してください。
(4) XML署名とXML暗号を併用する場合
XML署名とXML暗号を併用する場合は,アプリケーションを開発するときに次のことを考慮する必要があります。
(a) XML署名とXML暗号の順序性
XML署名とXML暗号を併用する場合,受信者は送信者がデータに署名を付与してから暗号化したのか,データを暗号化してから署名を付与したのかを知る必要があります。受信者は,送信者の処理と逆の順序で署名の検証およびデータの復号化を実行する必要があるためです。例えば,送信者が署名を付与してからデータを暗号化していた場合,受信者はまずデータを復号化してから署名を検証します。受信者が送信者と同じ順序で署名の検証およびデータの復号化を実行してしまった場合,署名の検証に失敗します。
(5) 共通鍵を3人以上で共有する場合
3人以上で共有している共通鍵は,その共通鍵を共有しているすべてのメンバに対して送信するデータを暗号化するときにだけ使用します。その共通鍵を共有しているメンバのうち,一部のメンバに対してだけデータを送信する場合は,使用しないでください。一部のメンバに対してだけデータを送信した場合でも,共通鍵を共有するほかのメンバがデータを盗聴すると,データを復号できてしまうため,情報が漏洩するおそれがあります。
(6) 暗号データの改ざんへの対策
一般的な暗号技術では,同じ鍵を使用して同じデータを暗号化した場合に暗号化結果が同じにならないように,IVとよばれるランダムな値を暗号化対象とともに暗号化することがあります。IVは,暗号化されたデータとともに送信されます。暗号化したデータにIVを付加することで,送信中に第三者によってデータが解読されるおそれは少なくなりますが,IV自体または暗号化されたデータの改ざんは防止できません。IVや暗号データが改ざんされると,復号化結果も異なってしまいます。IVまたは暗号データの改ざんを防止するためには,平文に対して署名するなどの対策が必要です。
(7) DoS攻撃への対策
XML署名またはXML暗号の相互参照などを悪用して無限再帰となる処理を要求したり,容量の大きいデータや常にリダイレクトを必要とするデータへの参照が必要となるデータを送信したりするなどのDoS攻撃への対策として,アプリケーションを開発する場合は次の機能を組み込んでおく必要があります。
-
再帰処理を制限する機能
-
1回の処理で使用できるリソースの容量を制限する機能
(8) 暗号データの安全性
XML暗号によって暗号化したデータは,コンピュータウィルスなどの有害なデータであっても,ファイアウォールやウィルスを検知するソフトウェアなどで検出できない場合があります。そのため,暗号化されたデータの安全性は保証されていないという前提で,ファイアウォールやウィルスを検知するソフトウェアには次の対処のどれかを実施することをお勧めします。
-
暗号データを拒否する。
-
安全なデータかどうかを確認するため,復号化したデータへのアクセスを要求する。
-
ローカルファイルへのアクセスを制限するなどして,データを受信したアプリケーションが任意のコンテンツを処理してもシステム全体のセキュリティを確保する。