アプリケーションプロトコル

SET ワンタイムパスワード
遠隔ログイン(SSH) Kerberos

SET

インターネット上でクレジット決済を行うためのプロトコル仕様 (Secure Electronic Transactions) である． IBM が開発した iKP をベースとし，利用者，商店，クレジット会社の3者間プロトコルを規定している．認証機関 (CA) の利用を前提としている．

SET ではインターネットを介して接続された以下の通信手順を規定している．

  1. 顧客 (Cardholder)
    買い手であり，インターネットを介して店舗と取引を行う．
  2. 店舗 (Merchant)
    売り手であり，インターネットを介して顧客と取引を行う．
  3. 認証機関 (CA:Certification Authority)
    顧客や店舗の申請する公開鍵データに認証をあたえる　(正当であることを証明する証明書を発行する) 機関
  4. 支払いゲートウェイ (Payment Gateway)
    Issuer (売り手の取引銀行又はそれに相当する機関) に対する与信依頼や，店舗に対する支払いサービス等の処理を行う．

SET におけるセキュリティ要件は次のとおりである．

技術仕様として，以下の仕様が提示されている．

ワンタイムパスワード

ワンタイムパスワード (OTP:One Time Password) は，パスワードを一度きりの使い捨てにし，認証が必要なシステムへアクセスするたびに毎回異なるパスワードを使うようにするものである．万一パスワードが盗み見られても，次回はそれを使わないので安全性が保たれる．

OTP の基本的な考え方は，あらかじめ認証し合う両者がパスワードの一覧表を持っておき，表中のパスワードを順番に使っていくというものである．実際には，表を持つ代わりにあらかじめ決められた規則に従って，双方でパスワードを生成して認証するようになっている． 具体的には，ユーザがホストにアクセスする場合，ホスト側からチャレンジと呼ばれる乱数値が送られる．ユーザは自分だけが知っているパスフレーズとチャレンジとを用いてある種の演算を行なった結果をホストに返す． ホストも，同じ演算を行なってパスワードを検証する．

遠隔ログイン (SSH)

遠隔ログインは，インターネット経由で遠隔地にあるコンピュータシステムへログインするための手段である． しかし，インターネット経由でログインを行なうと，パスワード情報やその他の情報が盗聴されたり，改ざんされる危険は避けられない． SSH (Secure SHell)は，rsh (リモートシェル)，rlogin (リモートログイン)や rcp (リモートコピー)などのリモートツールにセキュリティ機能を付加したものである． SSHにより認証機能と通信の暗号化が行える．

SSH サーバは，クライアントからの接続要求があると次のプロトコルを実行する．

  1. 互いの SSHプロトコル・バージョン番号の交換
    バージョン番号は次の形式を持った文字列であり，これらを交換することにより，互いのバージョンが適切なものであるかを確認する．

    SSH-<メジャー番号>-<マイナー番号>-<ソフトウェアバージョン>

    メジャー番号が同じバージョン間では，互換性が保証される．
  2. セッション鍵の交換
    Diffie-Hellman (DH) 法による鍵交換（セッション鍵の生成）を行う．
  3. クライアントの認証
    セッション鍵の交換が終了すれば，サーバとクライアントは同じセッション鍵を共有しているので，以後の通信は暗号化することができる． クライアントの認証には次の 4つの方式がある．
    1. /etc/hosts.equiv または ~/.rhostsによる認証
    2. a. に加えてホストのRSA認証
    3. ユーザのRSA認証
    4. パスワード認証
      上記の認証がすべて失敗したときに行なわれるもので，通常のログイン処理と同じである．クライアントから送られたパスワードをサーバ側で認証する． パスワードは暗号化されて送信されるので，盗聴等の問題はない．
  4. クライアントからの要求の処理

SSH では，上記のように最初に公開鍵暗号を用いてセッション鍵を交換し，それ以後は共通鍵暗号によりデータの暗号化が行なわれる．共通鍵暗号としては，IDES，DES，Triple DES，RC4 が用意されており，サーバとクライアントの交渉によって選択される．

SSH には異なるバージョンがあり，脆弱性の有無など細かい違いがある．SSH1 (プロトコル1) は，RSA 暗号を用いて認証を行い，通信の隠蔽のために 3DES や Blowfish などの暗号を用いる． SSH2 (プロトコル2) は，当初 RSA の特許問題の回避を意図して DSA 署名を用いて認証を行うように実装された．現在では，RSA の特許問題が解消したので SSH2 でも RSA 認証が使われている．

2 つのプロトコルの相違は，SSH1 がデータが改竄されていないかどうかのチェックに単純な CRC を用いていたのに対して，SSH2 ではより強力な HMAC アルゴリズムによるチェックが使われている点である．また，SSH2 では通信の隠蔽のための AES などの安全性の高い共通鍵暗号アルゴリズムを選べるように設計されているので，現在は SSH2 の方が推奨されている． なお，SSH1 と SSH2 の間には互換性がなく，両者が共通のプロトコルをサポートしていないと，通信ができないことになる．

Kerberos

Kerberos は，クライアントとサーバ間の認証と暗号化用の鍵の配布を Key Distribution Center (KDC:鍵管理センタ) を通して行なう方式である． すべての参加者は KDC を信頼し，KDC のみが信頼性の責任を持つことを前提にする． KDC は各参加者とそれぞれ秘密の鍵 (暗号鍵) を共有する．KDC はこの秘密の鍵を通じて参加者の身元を確認する．

以下の RFC に仕様がある．

ユーザ(クライアントプログラム) A がホスト(サーバプログラム) B に対する認証を行なう場合の手順は次のようになる．

  1. ユーザ A は KDC に対し，ホスト B に対するチケットの発行を依頼する．
  2. KDC はこの要求に対して，B に対するチケットを含む証明書と呼ばれるデータをユーザの鍵で暗号化したものをユーザに返す．
    この証明書には，B に対するチケットの他にセッション鍵が含まれている． チケットには，ユーザ A に関する情報とセッション鍵が含まれており，全体がホスト B の鍵で暗号化されている．
  3. ユーザ A は受けとった証明書を自分の鍵で復号し，チケットとセッション鍵を取り出す．このチケットをホスト B に送る．
  4. ホスト B は自分の鍵でチケットを復号し，ユーザ A の情報とセッション鍵を取り出す．

この手順により，ユーザ A とホスト B は同じセッション鍵を共有する．ホスト B は，チケット内の情報からユーザ A の身元が分かる．また，ユーザ A が KDC からの証明書を復号してチケットを取り出せたことから，チケットを送った相手が間違いなくユーザ A であると分かる． 一方，ユーザ A はホスト B とセッション鍵を用いて正しく通信が行なえれば，ホスト B が KDC が暗号化したチケットからセッション鍵を取り出せたことから，ホスト B は目的の相手であることが分かる． このように，第三者である KDC を介してユーザとホストが互いに相互認証できる．

inserted by FC2 system