
| 今回の内容 | |
|
浅野昌和
日本ボルチモアテクノロジーズ
2000/11/2
| インターネットにおける電子商取引のリスク |
インターネットが急速に普及し、商取引のインフラとしても当たり前のように使われるようになっている。特に最近ではASP(Application Service Provider)という形態でマーケットプレースの提供なども目立つようになってきている。
これに伴って、どのように電子商取引におけるセキュリティを保ち、安全性を確保するのかが大きな課題になっている。ここではまず、インターネットというインフラを電子商取引に使用する場合に、どのようなリスクが存在するのかを考えてみよう。主に以下の4つがそのリスクとして考えられている。
- 盗聴
- 改ざん
- なりすまし
- 否認
「盗聴」については解説するまでもないだろう。電子商取引においては企業のデータや取引データなど、他人に知られては困るものが飛び交うことになる。これらのデータを他人が盗み見てしまうというのがこの「盗聴」である。
上記の「盗聴」がインターネットにおける極めて一般的なリスクであるのに対し、「改ざん」は、電子商取引であるが故にその脅威が大きなものとなる性質を持っている。例えば、企業Aが企業Bに対して単価100円の商品を1000個注文したとする。この注文データをだれかが書き換え、10000個注文したことにしてしまうのである。
「なりすまし」は、文字通り第三者が正当な取引主体に成り済まして取引を行うといった行為だ。
そして、最後の「否認」だが、これは「改ざん」「なりすまし」と大きな関係を持っている。例えば、自分が行った注文行為を、「それは第三者が私に成り済まして行ったものだ」と言い張ったり、実は10000個の注文を出していたのに、「私が注文したのは1000個であり、だれかが注文データを改ざんして“0”を1つ付け加えたのだ」と主張したりして、自分の行った商行為を否定してしまうというものである。「改ざん」「なりすまし」の可能性が存在する以上、こういった主張に真っ向から反論することが非常に難しくなってしまう。
このように、実世界では顔を見合わせ、押印した書類を取り交わすことで回避できていたリスクが、インターネット上では歴然と存在してしまうのである。
| PKIってナニ? |
上記で述べたリスクを回避し、インターネット上で安全な商取引を行うためのインフラとして注目されているのがPKIだ。PKIとはPublic Key Infrastructureの略で、公開鍵暗号方式という暗号技術を使用したセキュリティ・インフラである。
公開鍵暗号方式とは古くから存在している共通鍵暗号方式(または対称鍵暗号方式)の欠点を解消するものとして考案されたものである。
共通鍵暗号方式とは、暗号化するための鍵とそれを復号化するための鍵に同じものを使用するという暗号化方式の総称である(図1)。
![]() |
| 図1 共通鍵暗号方式の暗号化と復号の仕組み |
この方式の場合、ある文書を暗号化した際に使用した鍵は、復号化する際にも必ず必要になる。例えば、ある文書をインターネットを介してAさんがBさんに送付する場合を考えてみよう。そうすると、AさんはBさんに対して、暗号化の際に使用した(あるいはする)鍵を何らかの、絶対に他人に知られないような方法を使って渡さなければならない。これは非常に大きな問題点だ。さらに、AさんがBさん以外に、Cさん、Dさんともやりとりしようと思った場合には、Cさん用、Dさん用にも鍵を用意し、それぞれの相手とそれを共有しなければならなくなってしまう。つまり、Aさんは暗号文のやりとりをする相手の数だけ鍵を保管し、しかもそれを厳重に管理しなければならないのである。
上記のような欠点があっては、インターネットというインフラを十分に活用することが非常に難しくなってしまう。
これに対して公開鍵暗号方式は暗号化と復号化で異なる2つの鍵を使用する(図2)。あらかじめキーペアと呼ばれる一対の鍵を生成し、それを使用するのだが、非常に特徴的なのは片方の鍵を使って暗号化したものはそれと対になっているもう一方の鍵を使用しなければ復号化できないということだ。この一対の鍵は便宜上「秘密鍵」と「公開鍵」と呼ばれている。
![]() |
| 図2 公開鍵暗号方式の暗号化と復号の仕組み |
先ほどのAさんとBさんの例を見てみよう。ここではBさんがAさんに暗号文を送付する場合を考えてみる。まずBさんはAさんの公開鍵を入手する。基本的にこの鍵の内容は誰が手に入れてもよいものなので、Aさんはそれを電子メールで送ってもよいし、自分のホームページ上に公開してもよい。BさんはAさんの公開鍵を入手したら、その鍵を使って送付したい文書を暗号化し、Aさんに送付する。受け取ったAさんは、自分の秘密鍵を使用してその文書を復号化するのである。Aさんの公開鍵で暗号化したものは、Aさんの秘密鍵でしか復号化できないため、仮に第三者がAさんの公開鍵を入手したとしても、暗号化された文書の内容が漏れてしまうことはないのである。逆にAさんの「公開鍵」を持っていれば、だれもがAさんと暗号文のやりとりができるようになる。暗号文をやりとりする相手が何人になろうと、Aさんが厳重に保管しなければならないのはAさんの秘密鍵だけということになる。
このように公開鍵暗号方式は共通鍵暗号方式に比べて、オープンなネットワークであるインターネットというインフラに非常に有効性が高い。
| 電子署名実現の仕組み |
上記で例として述べた暗号化は、最初に述べたリスクのうち「盗聴」、そして場合によっては「なりすまし」を防ぐのに有効な手段である。
さらに、公開鍵暗号方式を使用して電子署名というものが実現できる。これは、PKIの非常に特徴的で、しかも非常に有効な使用方法だと言える。
![]() |
| 図3 電子署名の原理 |
先ほど、「片方の鍵を使って暗号化したものはそれと対になっているもう一方の鍵を使用しなければ復号化できない」のが公開鍵暗号方式だと書いた。これはすなわち、公開鍵で暗号化したものは秘密鍵でしか復号化できないということとともに、秘密鍵で暗号化したものは公開鍵でしか復号化できないということでもある。電子署名はこれを利用している。
「公開鍵はだれにでも公開しているものなんだから、秘密鍵で暗号化することって意味がないんじゃないの?」と思われる方もいるだろう。ところが、これが大いに意味があるのだ。
電子署名の原理はこういうことだ。AさんがBさんにある文書を送ろうとしている。この文書(平文)とともに、文書を自分の秘密鍵で暗号化したものを一緒に送るのである。この2つを受け取ったBさんは、まず暗号化された文書をAさんの公開鍵で復号化する。それと平文を比較する。これが一致したとき、どのようなことが言えるだろうか。それは、「その文書はAさん以外のだれかによって改ざんされていない」ということが言えるのである。なぜならば、公開鍵を用いて復号化できる=それは対応する秘密鍵、すなわちAさんのみが持つ秘密鍵で暗号化された=暗号化したのはAさんに間違いない、という図式が成り立つからである(図3)。
実際の電子署名は、上記の原理にハッシュ関数というものを組み合わせて行われる。ハッシュ関数とは、以下のような特徴を持つアルゴリズムである。
- 元データの長さに関係なく、ハッシュアルゴリズムの出力値(これをハッシュ値という)は必ず決められた長さ(128ビットや160ビット)になる
- 元データが少しでも異なれば、ハッシュ値は大きく異なるものとなる
- ハッシュ値から元データを推測することはほぼ不可能である
上記のような特徴から、平文のハッシュ値を平文の代わりに秘密鍵で暗号化するという形が一般的だ(図4)。
![]() |
| 図4 ハッシュを用いた電子署名 |
この電子署名によって、「なりすまし」「改ざん」のリスクを回避することができ、結果として「否認」のリスクも回避することができるわけだ。
|
| 電子署名の作成と検証 |
それでは、実際に電子署名を付加する際の手順を具体的に見てみよう。
(1)相手に送信したい情報(平文)のハッシュを作成する
(2)作成したハッシュの内容を自分の秘密鍵で暗号化する(これが電子署名となる)
(3)平文と電子署名のペアを相手に送る
では、これを受け取った側はどのようにしてそれを検証したらよいのだろうか。以下にその手順を示す。
(1)相手の公開鍵を入手する
(2)その公開鍵で送付された電子署名を復号化する
(3)送付された平文から、相手と同じアルゴリズムを用いてハッシュを作成する
(4)(2)の結果と(3)で作成したハッシュを比較する
2つの値を比較した結果、両者が一致すれば送り手が署名してから受け手が署名を検証するまでの間にその文書が改ざんされていないことが検証されたことになる。
| 公開鍵と電子証明書 |
先ほど、公開鍵はだれが入手してもよく、どんな方法で相手に渡してもかまわないと書いた。では、公開鍵を受け取った人は、どのような方法でその持ち主を確かめるのだろうか?
公開鍵の持ち主(=その公開鍵に対応した秘密鍵の持ち主)を証明するものとして「電子証明書」というものが存在し、その証明書を発行する機関を「認証局」という。Aさんの公開鍵を受け取ったら(実際には証明書の中に公開鍵が含まれた形になっている)、証明書の内容に不備がないか、そしてその証明書を発行した認証局が信頼できる認証局かどうかで確認するということになる。電子証明書と認証局については、連載の中で詳細に触れていきたい。
|
|
| 「Master of IP Network総合インデックス」 |
TechTargetジャパン
- 実機では測定できない性能を測定? (2012/2/7)
システムの完成前に、達成し得る性能値や必要なサーバリソースを知るには? その解となる「性能シミュレーション技法」を解説 - 性能チューニング個所の検討 (2012/1/30)
アプリのチューニングや環境増強で、どの程度改善が見込める? 今回からは「実際に活用できる性能対策」を解説します - 遅いところを直すだけでいいのですか? (2012/1/24)
負荷が集中したときの性能ボトルネックを改善するのに、アプリケーションサーバとDB、どちらを優先すべきでしょう? - cloudfoundry.comを使ってみよう (2012/1/19)
VMwareが提供するPaaSプラットフォーム「CloudFoundry」。注目を集めるこの基盤を活用してPaaSを構築!
|
|
キャリアアップ
スポンサーからのお知らせ
- - PR -
イベントカレンダー
- - PR -




