EAP-MD5とは？意味をわかりやすく簡単に解説

text: XEXEQ編集部

EAP-MD5とは
EAP-MD5の認証プロセス
サーバーからクライアントへのチャレンジ送信
クライアントによるレスポンスの計算と送信
サーバーによるレスポンスの検証と認証結果の通知
EAP-MD5の脆弱性と問題点
平文でのパスワード送信によるセキュリティリスク
相互認証の欠如によるなりすまし攻撃の可能性
暗号化されていないチャレンジとレスポンスの盗聴リスク
EAP-MD5の代替となる認証方式
EAP-TLS: 証明書ベースの相互認証が可能な強力な認証方式
EAP-TTLS: サーバー認証とトンネル内での各種認証をサポート
PEAP: サーバー認証と内部EAP方式による柔軟な認証が可能
参考サイト

EAP-MD5とは

EAP-MD5はExtensible Authentication Protocol(EAP)の認証方式の一つであり、MD5(Message Digest 5)ハッシュアルゴリズムを用いたチャレンジレスポンス認証を行います。EAPはネットワークアクセスの認証に使用される汎用的なフレームワークで、様々な認証方式をサポートしています。

EAP-MD5ではサーバーがクライアントに対してチャレンジ(ランダムな値)を送信し、クライアントはそのチャレンジとパスワードを組み合わせてMD5ハッシュを計算します。計算されたハッシュ値はレスポンスとしてサーバーに返送され、サーバーも同様の計算を行って受信したレスポンスと比較することで認証の可否を判断するのです。

EAP-MD5は比較的シンプルな認証方式であり、実装が容易であるという利点があります。しかし、パスワードがハッシュ化されずに送信されるため、セキュリティ上の脆弱性が指摘されています。

また、EAP-MD5では相互認証が行われないため、クライアントがサーバーの正当性を確認することができません。このため、中間者攻撃などのセキュリティリスクがあり、現在ではより安全な認証方式の使用が推奨されています。

EAP-MD5はIEEE 802.1Xを使用したネットワークアクセス認証や、PPPを使用したダイヤルアップ接続の認証などで使用されてきました。しかし、セキュリティ上の問題から、現在では他のEAP方式やより安全な認証プロトコルが広く採用されるようになっています。

EAP-MD5の認証プロセス

EAP-MD5の認証プロセスに関して、以下3つを簡単に解説していきます。

サーバーからクライアントへのチャレンジ送信
クライアントによるレスポンスの計算と送信
サーバーによるレスポンスの検証と認証結果の通知

サーバーからクライアントへのチャレンジ送信

EAP-MD5認証が開始されると、サーバーはクライアントに対してチャレンジを送信します。このチャレンジはランダムな値で構成されており、クライアントがレスポンスを計算するための基となるデータです。

サーバーはチャレンジをEAPフレームにカプセル化して送信します。クライアントは受信したEAPフレームからチャレンジを取り出し、レスポンスの計算に使用することになります。

チャレンジは認証のたびに異なる値が使用されるため、リプレイ攻撃を防ぐ効果があります。ただし、チャレンジ自体は平文で送信されるため、盗聴によって取得される可能性があることに注意が必要です。

クライアントによるレスポンスの計算と送信

クライアントはサーバーから受信したチャレンジとパスワードを使用して、レスポンスを計算します。レスポンスの計算にはMD5ハッシュアルゴリズムが使用されます。

具体的にはクライアントはチャレンジとパスワードを連結した文字列を作成し、それをMD5でハッシュ化します。計算されたハッシュ値がレスポンスとなり、EAPフレームにカプセル化されてサーバーに送信されるのです。

レスポンスの計算に使用されるパスワードは平文のままハッシュ化されるため、パスワードの機密性が保護されません。このため、EAP-MD5ではパスワードが盗聴された場合、認証情報が漏洩するリスクがあります。

サーバーによるレスポンスの検証と認証結果の通知

サーバーはクライアントから受信したレスポンスを検証するために、同様の計算を行います。サーバーはクライアントに送信したチャレンジと、クライアントのパスワードを使用して、期待されるレスポンスを計算するのです。

計算された期待値と、クライアントから受信したレスポンスが一致する場合、サーバーはクライアントの認証を成功とみなします。認証結果はEAP-Successフレームとしてクライアントに通知され、クライアントはネットワークへのアクセスを許可されることになります。

一方、期待値とレスポンスが一致しない場合、サーバーは認証失敗とみなし、EAP-Failureフレームをクライアントに送信します。この場合、クライアントはネットワークへのアクセスを拒否され、再度認証を行う必要があります。

EAP-MD5の脆弱性と問題点

EAP-MD5の脆弱性と問題点に関して、以下3つを簡単に解説していきます。

平文でのパスワード送信によるセキュリティリスク
相互認証の欠如によるなりすまし攻撃の可能性
暗号化されていないチャレンジとレスポンスの盗聴リスク

平文でのパスワード送信によるセキュリティリスク

EAP-MD5ではクライアントのパスワードが平文のままハッシュ化されてレスポンスとして送信されます。これはパスワードの機密性を保護しないため、盗聴された場合にパスワードが漏洩する危険性があります。

攻撃者が認証プロセスを盗聴し、チャレンジとレスポンスを取得した場合、オフラインでパスワードのブルートフォース攻撃を行うことが可能です。これにより、パスワードが推測される可能性があり、重大なセキュリティリスクとなるのです。

したがって、EAP-MD5はパスワードの機密性を保護しない認証方式であり、セキュリティ上の脆弱性があると言えます。現在ではより安全な認証方式の使用が強く推奨されています。

相互認証の欠如によるなりすまし攻撃の可能性

EAP-MD5はクライアント認証のみを提供し、サーバー認証は行われません。つまり、クライアントはサーバーの正当性を確認することができず、攻撃者がサーバーになりすましてクライアントを欺く可能性があります。

攻撃者は偽のサーバーを設置し、クライアントにチャレンジを送信することで、クライアントのパスワードを取得しようとする可能性があります。クライアントが偽のサーバーを本物と信じてレスポンスを送信してしまうと、パスワードが攻撃者に漏洩してしまうのです。

相互認証の欠如は中間者攻撃などの脅威にもつながります。攻撃者が通信を傍受し、クライアントと本物のサーバーの間に割り込むことで、認証情報を盗聴したり、通信内容を改ざんしたりすることが可能になってしまいます。

暗号化されていないチャレンジとレスポンスの盗聴リスク

EAP-MD5ではチャレンジとレスポンスが暗号化されずに送信されます。これは認証プロセス全体が平文で行われることを意味し、盗聴による情報漏洩のリスクがあります。

攻撃者が認証プロセスを盗聴することで、チャレンジとレスポンスを取得し、オフラインでパスワードのブルートフォース攻撃を行うことが可能です。また、盗聴された情報を使用して、リプレイ攻撃を行う危険性もあります。

暗号化されていない通信はプライバシーの保護にも問題があります。認証プロセスで交換される情報が平文で送信されるため、通信内容が第三者に知られる可能性があるのです。

EAP-MD5の代替となる認証方式

EAP-MD5の代替となる認証方式に関して、以下3つを簡単に解説していきます。

EAP-TLS: 証明書ベースの相互認証が可能な強力な認証方式
EAP-TTLS: サーバー認証とトンネル内での各種認証をサポート
PEAP: サーバー認証と内部EAP方式による柔軟な認証が可能

EAP-TLS: 証明書ベースの相互認証が可能な強力な認証方式

EAP-TLS(Transport Layer Security)はクライアントとサーバーの両方が証明書を使用して相互認証を行う方式です。TLSプロトコルを使用して、セキュアな通信チャネルを確立し、その上で認証が行われます。

EAP-TLSではサーバー証明書とクライアント証明書の両方が使用されるため、なりすまし攻撃を防ぐことができます。また、証明書ベースの認証であるため、パスワードの漏洩リスクもありません。

ただし、EAP-TLSを使用するためにはクライアントとサーバーの両方で証明書を管理する必要があり、証明書の発行と配布にコストがかかります。また、クライアント側でも証明書のインストールと管理が必要となるため、ユーザーの利便性が低下する可能性があります。

EAP-TTLS: サーバー認証とトンネル内での各種認証をサポート

EAP-TTLS(Tunneled Transport Layer Security)はサーバー認証とセキュアなトンネルの確立を行った上で、トンネル内で様々な認証方式を使用できる方式です。外部認証ではサーバー証明書を使用し、内部認証ではパスワードベースの認証方式を使用することが一般的です。

EAP-TTLSではサーバー認証によってなりすまし攻撃を防ぐことができ、トンネル内の通信が暗号化されるため、盗聴によるパスワードの漏洩リスクを軽減できます。また、内部認証ではEAP-MD5よりも安全なパスワードベースの認証方式を使用できるのです。

EAP-TTLSはクライアント側に証明書が不要であるため、ユーザーの利便性が高く、導入コストも比較的低いという利点があります。ただし、サーバー側では証明書の管理が必要となります。

PEAP: サーバー認証と内部EAP方式による柔軟な認証が可能

PEAP(Protected Extensible Authentication Protocol)はEAP-TTLSと同様に、サーバー認証とセキュアなトンネルの確立を行った上で、トンネル内で他のEAP方式を使用して認証を行う方式です。PEAPはMicrosoftによって開発され、Windows環境での使用が一般的です。

PEAPではサーバー証明書を使用してサーバー認証を行い、トンネル内ではEAP-MSCHAPv2やEAP-GTCなどの各種EAP方式を使用して認証を行います。これにより、パスワードベースの認証だけでなく、トークンベースの認証など、多様な認証方式を柔軟に選択できるのです。

PEAPはEAP-TTLSと同様に、クライアント側に証明書が不要であるため、ユーザーの利便性が高く、導入コストも比較的低いという利点があります。また、Windowsとの親和性が高いため、Windows環境での導入が容易であると言えます。