悪意のある攻撃から身を守るには？

ハッシュ関数とは

　MACキーはハッシュ関数を使って作成します。ハッシュ関数というのは、手品で使われる黒い箱のようなもので、あるデータを入れるとそこから複雑になった別のデータが出てくる関数です。生成するビット長が異なるSHA-1やSHA-256があります。

　ハッシュ関数の面白いところは、「出てきたデータ（ハッシュ値）を見ても元のデータが想像できないこと」と「同じデータを入れると必ず同じハッシュ値が得られること」です。一般的には、黒い箱に入れる前に、少し塩を振りかけてより元のデータをわかりにくくさせたりします。つまり、元データに＋αのデータを足してインプットすることで、出てきたデータの強度が高まります。

　アソシエーションの処理の中では、PRとOPがやりとりする秘密の呪文が元データとなり、ハッシュ関数にかけると、一意の署名（MACキー）ができるということです。

署名（MACキー）＝秘密の呪文×ハッシュ関数

秘密の呪文の作り方

　上記で説明した署名（MACキー）の目的はお互いに正しい相手かどうかを知るために利用するので、秘密の呪文自体をお互いに共有していなければいけません。しかもほかの人にはわからないように2人の間で秘密にしていなければいけません。

　その方法が、Diffie-Hellman鍵交換（Diffie-Hellman Key Exchange）と呼ばれているプロトコルです。セキュリティー関連の本には必ず出てきますが、実際にその概念をきちんと理解することはなかなか難しいのではないでしょうか。

　非常に簡単に言うと、自分の秘密の呪文と相手の秘密の呪文を使って2人しか知らない1つの秘密の呪文を作るということです。

　例えば、AさんとBさんという人が2人の秘密の「呪文C」を作る場合、Aさんが自分の秘密の呪文Aから作った「呪文A'」をBさんに渡し、Bさんは自分の秘密の「呪文B」と合わせて、共通の呪文Cを作ります。Bさんから見た場合も同じです。

AがBに教えた「呪文A'」×Bが考えた「呪文B」⇒「呪文C」
BがAに教えた「呪文B'」×Aが考えた「呪文A」⇒「呪文C」

　非常に単純化すると、以下のようになります。

「呪文A」＝1
「呪文A'」＝3

「呪文B」＝2
「呪文B'」＝4

「呪文C」＝5

AがBに教えた「3」×Bが持っている「2」⇒「5」
BがAに教えた「4」×Aが持っている「1」⇒「5」

　やりとりされるのは、つまり、盗聴される可能性のあるのは、AがBに教えた「3」とBがAに教えた「4」ですが、それぞれ盗んだとしても「5」を知ることはできません。

　さらに、すでに説明したハッシュ関数で変換されているのでもともとのデータである「5」もわからないので、署名のMacキーを見たとしてもそこから元の値も知ることが難しくなるのです。

　ここまで、アソシエーションを行う場合のセキュリティーに関して見てきましたが、実は、このようなアソシエーションを行わずに、OPから認証された後、PRに戻ってきてからあらためてOPに認証されているかを確認するstatelessモード（関連付けをしないモード）もあります。

　mixiでもこのstatelessモードがサポートされていますが、PRが共有サーバーなどを使っていて、秘密鍵を保存しておけない、あるいは盗まれてしまう可能性がある場合にstatelessモードを使うことも可能です。