電子証明書配布には"罠"が潜んでいる - NetAttest EPSで作る鉄壁ネットワークセキュリティ

安全な企業無線LANを構築するために不可欠とも言えるIEEE 802.1X認証。前回まで、IEEE 802.1X認証が求められる背景と、クライアントの電子証明書を管理するために必要な基盤について解説してきた。

クライアントごとに異なる証明書をインストールする電子証明書認証は、複数ユーザが同じパスワードを共有するPSK(プレシェアードキー)認証や偽装が容易なMACアドレス認証などと異なり、企業無線LANに求められる強固なセキュリティを確保できる。しかし、勘違いしてはいけないのは、証明書を使えば必ず強固なセキュリティが確保できるわけではないという点だ。

たとえば、証明書の配布方法によっては、証明書を不正入手し正規端末になりすますことができるタイプのものがある。他人にパスワードが知られて悪用されるのと同じように、証明書自体が盗まれて悪用されるリスクがあるのだ。その場合、セキュリティレベルはパスワードを使う場合と同等であり、証明書を使っていることで安心してしまっている分、脇の甘いセキュリティと言えるかもしれない。

では、証明書を使ってセキュリティレベルを本質的に高めるには何に気をつければいいのか。今回は、証明書に潜む"罠"を見分け、どのようにすれば罠に嵌らないようにできるのかを、ソリトンシステムズが提供する認証サーバアプライアンス「NetAttest EPS」の機能を紹介しながら整理していこう。

ソリトンシステムズが提供する認証サーバアプライアンス「NetAttest EPS」

無線LANセキュリティ特集記事

1回目：MACアドレス制限は"効果ゼロ" - NetAttest EPSで見直す企業無線LANのセキュリティ
2回目：IEEE802.1Xの認証サーバ構築は難しくない!! NetAttest EPSが実現する、“専門家いらず”のセキュアな無線LAN認証構築!!
3回目: 電子証明書配布には"罠"が潜んでいる - NetAttest EPSで作る鉄壁ネットワークセキュリティ（本記事）

無線LANセキュリティ特集記事

【連載特別企画】今さら聞けない「無線LANセキュリティの基本」第1回無線LANセキュリティの概要
【連載特別企画】今さら聞けない「無線LANセキュリティの基本」第2回無線LANの認証環境を構築する
【連載特別企画】今さら聞けない「無線LANセキュリティの基本」第3回無線LANの認証環境を構築する

秘密鍵は"実印"、公開鍵は"印鑑証明"のようなもの

まず、電子証明書について、簡単におさらいしておきたい。電子証明書というと、「管理が面倒くさいもの」「手間とコストがかかるもの」という印象を持っている方も少なくないだろう。だが、仕組みをざっくりと理解してしまえば、それほど難解なものではない。むしろ、証明書を適切に扱うためには、どのようなものなのかを理解しておくことは欠かせない。

【電子証明書とは】電子証明書とは公開鍵(Public Key)暗号を応用してユーザーの身分などを証明するデータのセットのことを指す。公開鍵暗号には、秘密鍵(Private Key)と公開鍵(Public Key)があり、PKI(Public Key Infrastructure)と呼ばれるセキュリティ基盤を使って、身分の正当性を示す(認証する)。

ざっくりと理解するために、秘密鍵は「実印(印鑑)」、公開鍵は「印鑑証明」と考えればいいだろう。実印を持っているだけでは、その人が本人かどうかわからない。市役所などから印鑑証明を発行してもらい、実印と印鑑証明をペアにすることで、本人であることを証明する。同様に、PKIでは、利用者が本人であることを証明するために秘密鍵(実印)を持ってもらう。それに加えて、認証局(市役所)から公開鍵(印鑑証明)を発行してもらい、秘密鍵と公開鍵をペアにすることで、本人であることを証明するのだ。

秘密鍵を"実印"、公開鍵を"印鑑証明"と考えれば、電子証明書の理解は進みやすい（資料提供：ソリトンシステムズ）

ここでいう「秘密鍵と公開鍵をペアにする」とは、片方の鍵を使って暗号化したデータはペアのもう一方の鍵でしか複合できない、という意味だ。実際に認証を行う場合は、利用者の端末と証明書を管理するサーバ同士でこの鍵ペアをやりとりしあう。

証明書配布に潜む"罠"

この公開鍵暗号方式を利用するためには、最初に利用者の端末に、公開鍵(証明書)と秘密鍵をインストールする必要がある。電子証明書を利用するネットバンキングや行政サービスを利用した経験のある方はお分かりいただけると思うが、なんらかの方法で、公開鍵と秘密鍵をクライアントPCに取り込まなければ、安全な通信が確立できない。

証明書をクライアントPCに取り込むには、公開鍵(証明書)と秘密鍵がペアで格納されたPKCS#12ファイルが主に利用される。ここで問題になるのが、PKCS#12ファイル自体はコピーが可能という点だ。くわえて、秘密鍵のエクスポートが「可」に設定されている場合、秘密鍵のコピーも可能となる。つまり、メールやCDで証明書を配布する場合、悪意を持ったものがそれを入手すれば、容易に不正コピーできてしまうのだ。

デジタル証明書配布における課題（資料提供：ソリトンシステムズ）

先の例にたとえれば、実印と印鑑証明がセットで誰かの手に渡ってしまえば、なりすましが容易となるが、同様の事態が電子証明書でも発生し得る。これが証明書配布に潜む"罠"だ。

実際、この罠を悪用した攻撃が2014年に国内で確認され大騒ぎになった。この攻撃では、法人向けネットバンキングサービスを標的にして、秘密鍵が「エクスポート可」の状態で格納された電子証明書を盗み出していたという。この攻撃を受けて、各銀行が法人向けネットバンキングで利用する秘密鍵を原則「エクスポート不可」「秘密鍵の保護：高」を推奨するようになった。

気をつけなければならないのは、こうした証明書を盗み取る被害に遭うのは、ネットバンキングだけに限らないということだ。安全な無線LAN環境を構築するために証明書を配布する際も、不正コピーができるようにしていれば、セキュリティは確保することはできない。

"罠"に嵌らない仕組みを検討すべし

IPA「2014年8月の呼びかけ」によると、法人口座の不正送金被害は、件数・金額共に2014年に急増している

解決策として望ましいのは、こうした"罠"に嵌らない仕組みを採用することである。とはいえ、最近のサイバー攻撃は巧妙だ。秘密鍵をエクスポート不可に設定しただけでは攻撃への根本的な対策にはならなくなっている。

実際、近年のネットバンキング詐欺の攻撃者は以下のような手段を取り、秘密鍵の取得を行うという。

【エクスポート設定を「不可」としてインポートした電子証明書を窃取する手口】

・対象端末内の電子証明書を、不正プログラムで削除
⇒・ユーザは、銀行に証明書の再発行を依頼
⇒・ユーザが再発行された証明書をインポートするタイミングで、不正プログラムがそれをコピー
⇒・コピーされた証明書を攻撃者のサーバーに送信

参考：IPA「2014年8月の呼びかけ」

こうした攻撃は、「エクスポート不可だから」と安心してしまい脇が甘くなってしまった面を狙われたと言える。対症療法的な対策は、高度化するサイバー攻撃に対して無力といってもいいかもしれない。

こうした状況に対し、ソリトンのNetAttest EPSでは、PKCS#12ファイル自体を扱わないというアプローチを採用している。具体的には、秘密鍵をユーザのクライアント端末で生成し、生成された秘密鍵は、端末外・通信経路に一切出さないというものだ。

端末内の秘密鍵は申請時にエクスポート不可で生成されるため、物理的に盗み取ることができない仕組みとなっている。通常、こうした証明書の生成と配布は、LANなどの閉じたネットワーク環境でのみ有効だったが、NetAttest EPSは、NetAttest EPS-apというモバイル対応のProxyサーバと連携することで、インターネット越しでも安全に証明書を配布できるようになっている。PCだけでなく、iOS、AndroidやMac OSデバイスなど、各種クライアント端末に対して証明書の配布や設定の自動化が可能だ。

PKCS#12ファイル自体を扱わない、NetAttest EPSの方式（資料提供：ソリトンシステムズ）

利便性を損なわず、管理者の手間も削減し、ネットワークセキュリティを高められる

セキュリティを強化しようとすると、利便性が損なわれ運用工数も多大になり、トレードオフの関係に陥るケースは少なくない。だが、注目したいのは、NetAttest EPSの秘密鍵生成と証明書配布の仕組みは、利便性をまったく損なわず、そのうえ管理者の手間も大幅に軽減できる点にある。くわえて、NetAttest EPSは、証明書の配布以外にも様々な機能に対応した統合認証基盤だ。

企業ネットワークという点からは、証明書の配布にかぎらず、無線クライアント(WiFi)の設定配布も欠かせない機能になるし、エンタープライズ環境への対応という意味では、複数拠点への分散配置や機器の冗長化、バックアップ・リストア機能なども必要だ。さらに、最近の働き方の変化を受け、リモートワークやモバイルワークを実現していくというニーズもある。NetAttest EPSは、こういったニーズにも柔軟に対応できる機能を備えている。

企業の無線LANセキュリティ対策の見直しが急務となるなか、IEEE 802.1X認証に対応した統合認証基盤構築の有力候補として検討してみてはいかがだろうか。