JP2017220769A

JP2017220769A - 通信システム及び方法、クライアント端末並びにプログラム

Info

Publication number: JP2017220769A
Application number: JP2016113192A
Authority: JP
Inventors: 優太郎清村; Yutaro Kiyomura; 麗生吉田; Reisei Yoshida; 鉄太郎小林; Tetsutaro Kobayashi
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2016-06-07
Filing date: 2016-06-07
Publication date: 2017-12-14

Abstract

【課題】従来よりも安全性の高い通信を実現することができる通信技術を提供する。
【解決手段】クライアント端末１、サーバ装置２及び証明書発行装置３を含む通信システムであって、クライアント端末１が、サーバ装置２と秘密通信を行う際に、任意の情報を生成して、サーバ装置２に送信し、サーバ装置２が、サーバ証明書の発行要求に生成された情報を含めて、証明書発行装置３に送信し、証明書発行装置３が、サーバ装置２の認証を行い認証に成功した後に、サーバ証明書の発行要求に基づいてサーバ装置２のサーバ証明書を生成して、サーバ装置２に送信し、サーバ装置２が、受信したサーバ証明書をクライアント端末１に送信し、クライアント端末１が、受信したサーバ証明書を検証して、検証により得られる情報の中に生成された情報と一致するものがあるかを確認し、一致するものがあると確認できた場合にサーバ装置２と秘密通信を行う。
【選択図】図１

Description

この発明は、情報通信分野における認証技術に関する。

近年、攻撃者がクライアントのID/PW等の個人情報を窃取することを目的として、クライアントを不正なWebサイトに誘導するフィッシング攻撃が起こっている。JPCERT/CCの報告によると、フィッシングサイトの件数は、2013年：1831件、2014年：1889件、2015年：1953件と年々増加している（例えば、非特許文献１参照。）。フィッシングサイトへの対策として、サーバ証明書の導入を行っている。しかし、近年では不正なサーバ証明書を用いたフィッシングサイトが出現しており、クライアントがアドレスバーの色だけでは本物のサイトかどうかを確認できないような事例も報告されている（例えば、非特許文献２，３参照。）。これは、攻撃者が認証局に不正侵入することで発行されたサーバ証明書を用いて、クライアント端末に不正なWebサイトを信頼させる事例である。

不正なWebサイトを信頼しないようにするための既存の技術には、EV SSLサーバ証明書（例えば、非特許文献４参照。）とPublic key Pining Extension for HTTP（例えば、非特許文献５，６参照。）がある。

まず、EV SSLサーバ証明書について説明する。EV SSLサーバ証明書は、サーバ装置と認証局である証明書発行装置間で、サーバ装置のドメイン情報の確認、登記事項証明書による法的実在性の確認、物理的実在性の確認を10日以上かけて行うことで発行される証明書である。クライアント端末は、サーバ装置と通信を行う際に、サーバ装置から提示されるEV SSLサーバ証明書が認証局から発行されたものであることをクライアント端末が予め持つルート証明書で確認できたら、Webサイトを信頼する仕組みである。EV SSL証明書の特徴は、ブラウザのアドレスバーが緑色になり、Webサイトの情報であるドメイン名、所在地、組織名等が表示することで、クライアント端末が正規のWebサイトを信頼していることを確認しやすいユーザインターフェイスになっていることである。しかし、近年この特徴を利用したフィッシングサイトが出現している。それに対して、失効リストによる対策があるが、失効リストによる対策が有効に機能していない等の理由により、失効されていない不正なサーバ証明書を検証できるため、EV SSL証明書による対策がしきれておらず、不正なサーバ証明書が有効な間は不正なWebサイトを信頼できてしまう。

次に、Public key Pining Extension for HTTPについて説明する。これは、Googleが、近年起こった認証局への不正侵入によりGoogleのサーバ証明書が発行されたことを受けて考案された、不正なサーバ証明書を検知する手法である。この仕組みについて、以下説明する。まず、ステップ1として、クライアント端末からサーバ装置へのリクエストに対して、サーバ装置から提示されるサーバ証明書の公開鍵のハッシュ値をレスポンスヘッダとして受け取り、そのハッシュ値を決められた有効期間ブラウザに登録する。次に、ステップ2として、サーバ装置から提示されたサーバ証明書のハッシュ値とブラウザに登録されたハッシュ値を比較し、一致したらそのWebサイトを信頼する仕組みである。ステップ1において、ハッシュ値の有効期限内にクライアント端末がサーバにアクセスした際は、有効期限が更新され、ハッシュ値の登録有効期間を過ぎた場合は、ブラウザから自動的に削除される仕組みになっている。もし、攻撃者が、認証局から不正に発行されたサーバ証明書の公開鍵のハッシュ値をレスポンスヘッダとしてクライアント端末に送るようなサーバを用意した場合、上記の仕組みを用いても、不正なサーバ証明書が有効な間は不正なWebサイトを信頼できてしまう。

上記で説明した既存の対策は、ダウンロードしてきたサーバ証明書が認証局に発行されたものかどうかを確認することはできるが、サーバ証明書の発行手順を確認することはできない。すなわち、サーバ証明書が認証局から認証・認可を受けて発行されたものなのか、不正侵入によって発行されたものなのか、区別をすることができない。そのため、クライアントは不正なWebサイトを信頼してしまう可能性があった。

JPCERT/CC,"インシデント報告対応レポート",［平成28年5月30日検索］、インターネット〈URL：https://www.jpcert.or.jp/ir/report.html〉 NETCRAFT,"Certificate authorities issue SSL certificates to fraudsters",［平成28年5月30日検索］、インターネット〈URL：http://news.netcraft.com/archives/2015/10/12/certificate-authorities-issue-hundreds-of-deceptive-ssl-certificates-to-fraudsters.html〉 "認証局発行の正規のSSL証明書もフィッシング詐欺で悪用のおそれ",［平成28年5月30日検索］、インターネット〈URL：http://news.mynavi.jp/news/2015/10/14/288/〉グローバルサイン,"EV SSL証明書",［平成28年5月30日検索］、インターネット〈URL：https://jp.globalsign.com/service/ssl/ev.html〉 "Public Key Pining Extension for HTTP", RFC 7469,［online］、［平成28年5月30日検索］、インターネット〈URL：https://tools.ietf.org/html/rfc7469〉 "不正なSSL証明書を見破るPublic Key Pinningを試す",［online］、［平成28年5月30日検索］、インターネット〈URL：http://d.hatena.ne.jp/jovi0608/20140902/1409635279〉

従来のPKIの仕組みでは、サーバ証明書が認証局に一時的に侵入された期間に発行されたものなのか、侵入された期間以外で認証局として機能している期間に発行されたものなのかを、クライアント端末は区別することができない。失効リストの仕組みでは、侵入されて発行された証明書を無効化できるが、無効化されるまでの期間は、クライアントがそのサーバを認証してしまう可能性があった。

この発明の目的は、従来よりも安全性の高い通信を実現することができる通信システム及び方法、クライアント端末並びにプログラムを提供することである。

この発明の一態様による通信システムは、クライアント端末、サーバ装置及び証明書発行装置を含む通信システムであって、クライアント端末が、サーバ装置と秘密通信を行う際に、任意の情報を生成して、サーバ装置に送信し、サーバ装置が、サーバ証明書の発行要求に生成された情報を含めて、証明書発行装置に送信し、証明書発行装置が、サーバ装置の認証を行い認証に成功した後に、サーバ証明書の発行要求に基づいてサーバ装置のサーバ証明書を生成して、サーバ装置に送信し、サーバ装置が、受信したサーバ証明書をクライアント端末に送信し、クライアント端末が、受信したサーバ証明書を検証して、検証により得られる情報の中に生成された情報と一致するものがあるかを確認し、一致するものがあると確認できた場合にサーバ装置と秘密通信を行う。

秘密通信ごとにサーバ証明書の発行及び検証を行うことにより、従来よりも安全性の高い通信を実現することができる。

通信システムの例を説明するためのブロック図。通信方法の例を説明するための流れ図。

以下、図面を参照して、この発明の一実施形態について説明する。

通信システムは、クライアント端末１、サーバ装置２及び証明書発行装置３を例えば備えている。

通信方法は、通信システムの各部が、図２又は以下に説明するステップＳ１からステップＳ５の処理を行うことにより実現される。

＜ステップＳ１＞
クライアント端末１は、サーバ装置２と秘密通信を行う際に、任意の情報を生成して、サーバ装置２に送信する（ステップＳ１）。秘密通信とは、例えばTLS（Transport Layer Security）通信である。

例えば、クライアント端末１の乱数生成部１１が、任意の情報として乱数の生成を生成する。この任意の情報である乱数は、証明書発行装置３により認証・認可が行われることにより発行されたサーバ証明書であることをクライアント端末１が後に確認するために用いられる。

任意の情報は、乱数に限定されず、文字列、ビット列等であってもよい。

＜ステップＳ２＞
サーバ装置２は、サーバ証明書の発行要求にクライアント端末１により生成された情報を含めて、証明書発行装置３に送信する（ステップＳ２）。

サーバ証明書の発行要求は、例えばいわゆるCSR（Certificate Signing Request）である。以下、サーバ証明書の発行要求のことをCSRと略記することもある。

＜ステップＳ３＞
証明書発行装置３は、証明書要求受信部３１で、サーバ装置２から送信されたサーバ証明書の発行要求を受け取る。

そして、証明書発行装置３は、サーバ装置２の認証を行い認証に成功した後に、サーバ証明書の発行要求に基づいてサーバ装置２のサーバ証明書を証明書発行部３３により生成して、サーバ装置２に送信する（ステップＳ３）。

サーバ装置２の認証は、証明書発行装置３の認証処理部３２とサーバ装置２の認証処理部２１との間で例えば行われる。サーバ証明書の生成は、証明書発行部３３により行われる。サーバ証明書の送信は、証明書送信部３４により行われる。

認証を行うために、サーバ装置２を持つ企業の実在確認等を予め行い、サーバ装置２が持つドメイン名を証明書発行装置３に登録しておく。サーバ装置２から送信されたサーバ証明書の発行要求に含まれるドメイン名が、証明書発行装置３に予め登録されたドメイン名であるかを認証処理部３２が確認をして、ドメイン名が一致していると確認できた場合には、認証に成功したとしてもよい。

例えば、証明書発行装置３の秘密鍵でサーバ証明書の発行要求に署名を行うことにより、サーバ証明書の生成が行われる。

＜ステップＳ４＞
サーバ装置２は、証明書発行装置３から受信したサーバ証明書をクライアント端末１に送信する（ステップＳ４）。サーバ証明書の受信は、証明書発行装置３の証明書受信部３１で行われる。

＜ステップＳ５＞
クライアント端末１は、サーバ装置２から受信したサーバ証明書を検証して、検証により得られる情報の中に上記生成された情報と一致するものがあるかを確認し、一致するものがあると確認できた場合にサーバ装置２と秘密通信を行う（ステップＳ５）。

サーバ証明書の検証は、クライアント端末１の証明書検証部１２により、予め記憶されている証明書発行装置３が公開するルート証明書を用いて行われる。

ステップＳ１において任意の情報として乱数が生成された場合には、証明書検証部１２は、検証されたサーバ証明書に乱数生成部１１で生成した乱数が含まれていることを確認する。確認できたら、クライアント端末１は、サーバ装置２を信頼することができる。

このように、秘密通信ごとにサーバ証明書の発行及び検証を行うことにより、従来よりも安全性の高い通信を実現することができる。

［プログラム及び記録媒体］
通信システム及び方法において説明した処理は、記載の順にしたがって時系列に実行されるのみならず、処理を実行する装置の処理能力あるいは必要に応じて並列的にあるいは個別に実行されてもよい。

また、クライアント端末１、サーバ装置２及び証明書発行装置３の各装置における各処理をコンピュータによって実現する場合、クライアント端末１、サーバ装置２及び証明書発行装置３のそれぞれが有すべき機能の処理内容はプログラムによって記述される。そして、このプログラムをコンピュータで実行することにより、これらの各装置の各処理がコンピュータ上で実現される。

この処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、例えば、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリ等どのようなものでもよい。

また、各処理手段は、コンピュータ上で所定のプログラムを実行させることにより構成することにしてもよいし、これらの処理内容の少なくとも一部をハードウェア的に実現することとしてもよい。

［変形例］
その他、この発明の趣旨を逸脱しない範囲で適宜変更が可能であることはいうまでもない。

１クライアント端末
１１乱数生成部
１２証明書検証部
２サーバ装置
２１認証処理部
３証明書発行装置
３１証明書要求受信部
３２認証処理部
３３証明書発行部
３４証明書送信部

Claims

クライアント端末、サーバ装置及び証明書発行装置を含む通信システムであって、
上記クライアント端末が、上記サーバ装置と秘密通信を行う際に、任意の情報を生成して、サーバ装置に送信し、
上記サーバ装置が、サーバ証明書の発行要求に上記生成された情報を含めて、証明書発行装置に送信し、
上記証明書発行装置が、上記サーバ装置の認証を行い認証に成功した後に、上記サーバ証明書の発行要求に基づいて上記サーバ装置のサーバ証明書を生成して、上記サーバ装置に送信し、
上記サーバ装置が、受信したサーバ証明書を上記クライアント端末に送信し、
上記クライアント端末が、受信したサーバ証明書を検証して、検証により得られる情報の中に上記生成された情報と一致するものがあるかを確認し、一致するものがあると確認できた場合に上記サーバ装置と上記秘密通信を行う、
通信システム。
請求項１のクライアント端末。
クライアント端末、サーバ装置及び証明書発行装置により行われる通信方法であって、
上記クライアント端末が、上記サーバ装置と秘密通信を行う際に、任意の情報を生成して、サーバ装置に送信するステップと、
上記サーバ装置が、サーバ証明書の発行要求に上記生成された情報を含めて、証明書発行装置に送信するステップと、
上記証明書発行装置が、上記サーバ装置の認証を行い認証に成功した後に、上記サーバ証明書の発行要求に基づいて上記サーバ装置のサーバ証明書を生成して、上記サーバ装置に送信するステップと、
上記サーバ装置が、受信したサーバ証明書を上記クライアント端末に送信するステップと、
上記クライアント端末が、受信したサーバ証明書を検証して、検証により得られる情報の中に上記生成された情報と一致するものがあるかを確認し、一致するものがあると確認できた場合に上記サーバ装置と上記秘密通信を行うステップと、
を含む通信方法。
請求項２のクライアント端末としてコンピュータを機能させるためのプログラム。