<前の日記(2005年01月14日) 次の日記(2005年01月20日)> 最新 編集

高木浩光@自宅の日記

目次 はじめに 連絡先:blog@takagi-hiromitsu.jp
訪問者数 本日: 2117   昨日: 1295

2005年01月15日

民間ブランドが行政機関には無益なのならVeriSign独占化を避けるべき

11日の日記 に対して、「昨日自分で書いた『オレオレ証明書』という言い方が気に入ってきた」というトラックバック を頂いた。「オレオレ証明書」……ソレダ! 使わせて頂く。 オレオレ証明書を発行するのは、「オレオレ中の認証局」といったところか。

11日の日記 の広島市、高知県の事例と、14日の日記の 埼玉県、川崎市の事例とは分けて考える必要がある。後者は、まがりなりにもLGPKI(地方公共団体における組織認証基盤) の利用を前提としており、抗弁可能なケースであるのに対し、前者は、 オレオレ中の認証局発行のオレオレ証明書を使っていて、LGPKIを利用する必 要性さえ理解されていないケースであり、まるっきり論外であった。

広島市と高知県のような事例はさすがに珍しいと思われるが、埼玉県や川崎市 のような事例は全国に何百、何千と存在すると思われる。WebのSSLサーバ証明 書にLGPKIを使っているところでは、どうしても「セキュリティの警告」が出 てしまう。埼玉県の事例だけをとりあげたのは、子供に無視させていたことと、 「全く問題ありませんので」と特に酷い表現を使っていたためである。フィン ガープリントを正しい方法で確認させていないところは、地方公共団体ではほ とんどすべてがそうだろう。

LGPKIは国策なのだから、たとえいくらかの課題が残されていようとも正当性 があるということになる。埼玉県の担当者が口にしていたように、LGPKIが 「まだ始まって間もない」ためにルート証明書が標準搭載されていないだけで、 将来は標準搭載されるというのであれば、LGPKIという仕組み自体は間違いで はなかろう。標準搭載できていない段階で使わせるべきでないというのが正論 だが、それを言っていると普及が始まらないという抗弁が可能なのだろう。

しかし、その「工事中状態」を長く続けることは弊害が大きすぎる。「この警 告は無視してよい」、「全く問題ない」という認識が地方公務員たちの間で常 態化しつつあるようだし、それを市民に解説するコンテンツまで作られている。 高知県や広島市がLGPKIの意義まで忘れてしまったのは、これの影響だろう。

その一方で、Windowsやブラウザに標準搭載のルート認証機関から認証パスを 辿れる証明書(つまりいわゆる「ベリサインなどの証明書」)で https:// ペー ジを提供している地方公共団体もいくつか存在する。地方公共団体がそうした 証明書を使うことを国から禁じられているわけではないようだ。

日経BPの日経ガバメントテクノロジーで「使える電子申請を目指して」の連載を執筆された牟田学氏のサイト「Manaboo's Room」で、 都道府県の電子申請システムの稼働状況がリンク集として整 理されている。

このリンク集をお借りして、各都道府県がSSLにどんなサーバ証明書を使って いるかをリストアップしてみた。これを表1に示す。 「○」は警告が出ないサイト、「なし」はリストに未掲載の都道府県、「不明」 はSSLの使われているページが見つからなかったことを表す。

表1: 都道府県電子申請で使用されるSSLサーバ証明書の種類
都道府県ドメイン名とシステムへのリンク警告発行認証局
北海道 shinseido.ar.pref.hokkaido.lg.jp × LGPKI Application CA
青森県なし
岩手県 www2.pref.iwate.jp VeriSign International Server CA - Class 3
宮城県なし
秋田県なし
山形県なし
福島県なし
茨城県 www1.asp-ibaraki.jp Verisign/RSA Secure Server CA
栃木県 www.ds.pref.tochigi.lg.jp × LGPKI Application CA
群馬県なし
埼玉県 eshinsei.pref.saitama.lg.jp × LGPKI Application CA
千葉県なし
東京都 www.shinsei.metro.tokyo.jp × LGPKI Application CA
神奈川県なし
新潟県 www.shinsei.pref.niigata.jp VeriSign International Server CA - Class 3
富山県 shinsei.kyodo-toyama.jp Verisign/RSA Secure Server CA
石川県 www.shinsei.pref.ishikawa.jp × LGPKI Application CA
福井県なし
山梨県 www.ycma.jp Verisign/RSA Secure Server CA
長野県なし
岐阜県 egov.pref.gifu.lg.jp × LGPKI Application CA
静岡県なし
愛知県 www.shinsei.e-aichi.jp Verisign/RSA Secure Server CA
三重県 www.shinsei.pref.mie.jp × LGPKI Application CA
滋賀県 www5.pref.shiga.jp × LGPKI Application CA
京都府なし
大阪府 www.shinsei.pref.osaka.jp Verisign/RSA Secure Server CA
兵庫県 sinsei2.pref.hyogo.jp Verisign/RSA Secure Server CA
奈良県 www1.shinsei.pref.nara.jp Verisign/RSA Secure Server CA
和歌山県なし
鳥取県なし
島根県 shisetsu.elg-shimane.jp VeriSign International Server CA - Class 3
岡山県 www.e-entry.okix.jp × LGPKI Application CA
広島県 www.shinsei-hiroshima.jp Verisign/RSA Secure Server CA
山口県 www1.shinsei.pref.yamaguchi.lg.jp × LGPKI Application CA
徳島県 www.tok-j.info × LGPKI Application CA
香川県 kds.pref.kagawa.jp × LGPKI Application CA
愛媛県 www.pref.ehime.jp × LGPKI Application CA
高知県 www.cdc.net-kochi.gr.jp × オレオレ中の認証局 Substantive test CA
福岡県 www.shinsei.pref.fukuoka.lg.jp × LGPKI Application CA
佐賀県なし
長崎県 eap.pref.nagasaki.jp × LGPKI Application CA
熊本県なし
大分県 www.egov-oita.pref.oita.lg.jp × LGPKI Application CA
宮崎県なし
鹿児島県 www.kagoshima-e-shinsei.jp × LGPKI Application CA
沖縄県不明

集計してみると、LGPKIを使用しているところが 17箇所、VeriSignを使用して いるところが 10箇所である。オレオレの高知県を除くと、SSLの申請システム を開始しているところの 37パーセントが LGPKI以外の証明書を使用している。

ドメイン名が「lg.jp」か否かということとの関係を見てみると、「lg.jp」ド メインのサイトでLGPKI以外が使われているところは存在しないことがわかる*1

といっても「lg.jp」ドメインを使っているところは 7箇所しかない。そして、 「lg.jp」ドメインでないのにLGPKIを使っているところが 10箇所ある。

しかし、LGPKI以外を使っているところのすべてが、VeriSignを使っていると いうのは、イカガなものか。

そもそもなぜ、警告が出て安全でないのに(そして市民の安全意識さえも蝕む のに)LGPKIを推進しようとするのか、その背景に何があるかというと、推進 させようとする人達に「外国の会社を頼るわけにいかない」という意識がある ものと思われる。埼玉県の担当者も、しきりに「アメリカの会社」という言葉 を繰り返していた。

WebにおけるPKIの仕組みを理解していない非技術者の行政官の思考では、 「外国にわが国の行政機関を『認証』してもらうなど組織の仕組み上あり得な い」ということもあろう。だが、その理屈は、サーバ証明書の役割を誤って理 解している場合にのみ成り立ち得る。

というのは、まず、サーバ証明書がもたらす効果には次の3つがある。

  1. 暗号化の鍵として使われ、受動的な盗聴と直接的な改竄を防止する。
  2. 通信相手が意図したアクセス先のドメイン名と一致する本物であること を保証する。その結果として、なりすましを防止し、能動的な盗聴も防止する。
  3. そのサイトを運営する組織の実在性を証明する。

これら3つの効果のうち、3番目の実在証明は、SSLが正しく働くという意味に おいては、必須のものではない。

民間の会社では、「co.jp」などのドメイン名を使うことになるが、そのドメ イン名が、本当にその会社のものなのかということは、whoisデータベースで 調べればわかるものの、一般の人にwhoisを使うわけにもいかないので、 サーバ証明書の発行先の組織名を読んでもらうことによって、閲覧者にその 会社のドメイン名であることを信じてもらうことができる。

また、マイナーな会社であれば、本当にそんな会社が存在するのかという疑問 を持たれることもあろう。そのときに、SSLでサーバ証明書を示していれば、 VeriSignなどの一定の審査をパスした会社だということを、閲覧者に示すこと ができる。(その信頼性を実現するため、個人にはサーバ証明書を発行しない 方針をとっている認証局が多い。)これが「実在証明」である。

行政機関であれば、そうした実在証明は不要だ(実在を証明するという発想自 体が社会システム上あり得ない話)ということになるし、whoisの代替という 点では、「.lg.jp」ないし「pref.都道府県名.jp」、「city.市町村名.都道府 県名.jp」や「.go.jp」のドメイン名を使っていれば、その役割も不要という ことになる。

これが、行政官の思考を「民間認証局の証明書を使うな」という方向に傾けさ せているのだろう。

もし、サーバ証明書の役割が実在証明だけであるのなら、その行政官的発想は 間違いではないかもしれない。しかし実際には、技術的にサーバ証明書には、 1.と 2.の役割ものあるのであり、そちらが不可欠なのだから、3.が単に不必 要だという事実から「民間認証局の証明書を使うな」という結論を導くのは論 理的に誤った思考である。

また、1.や 2.の機能を得るにしても、外国のサービスに頼っていては安全保 障上の問題があるという発想もあるのだろう。この発想の詳細は次の2つに分 けられる。

  • 外国の認証局が悪意を持ってわが国の組織の偽の証明書を発行する攻撃 をしかけてくるおそれがある。
  • 外国の認証局がわが国に対するサービスを停止してしまうおそれがある。

前者については技術的に誤りである。なぜなら、それはたとえ国内の認証局を 使っていても防げないからだ。Windowsやブラウザの証明書ストアには、多数 の外国のルート認証局が登録されており、その1つがそのような悪意を持てば その攻撃にさらされるのであり、サーバ証明書をそれらの認証局に発行しても らっているかどうかは関係がない*2。――(1)

後者については、サービスを停止された時点で、国内の認証局発行の証明書に 切り替えて使えばよい。サーバ証明書は、文書に対する署名などとは違って、 いつでも新しい証明書に換えてかまわないからだ。

以上のことから、民間の認証局を使ってはならないとする正当な理由は存在し ないことになる。

そして、現時点ではLGPKIを使うと、SSLの 2.の役割が機能しない(ルート証 明書を安全に入れることを子供や知事に説明するの無理だろう)という不具合 があるのだから、民間の認証局を使ったほうがよい理由が存在することになる。

しかしながら、表1のように、LGPKI以外の認証局がすべてVeriSignになってい るというのは、必要なことではない。

VeriSignがもてはやされていて、認証局の代名詞のように言われている*3のは、VeriSignのブランド 価値が高く評価されているからだろう。 その源はおそらく、VeriSign社がRSA Data Security社から分社化された子会 社だったことに由来するのだろう。RSA Data Securityは、公開鍵暗号として 老舗のRSAアルゴリズムの特許を保有していた会社であることから、技術的な 信頼がおかれているものと思われる。 ただ、VeriSignに対する(技術的ではなく)サービス運営上の信頼性がどこか ら生じているのかは知らない。

仮に、VeriSignの証明書発行サービスが他社に比べて安全確実な信頼性の高い ものであるとすると、実在証明の目的で証明書を取得したい者の立場からすれ ば、VeriSignブランドは有難いものということになるのだろう。「セキュアシー ル」なんかを貼って、「当サイトはベリサインセキュアサイトです」などといっ た謳い文句を掲げることに、ある程度の意義はあるのかもしれない。

しかし、実在証明を必要としていない行政機関には、そのブランド価値はほと んど不要である。SSLの 1.と 2.の機能を得たいだけであれば、どこの認証局 から買ってきても同じである。その理由は前述の(1)と同じで、信頼性の低い どこかの認証局が誤って悪意ある人物に証明書を渡してしまう事態が起きたと きには、いくらサイト側が信頼できる認証局から証明書を買っていても、閲覧 者側はいずれにせよ偽の証明書に騙されることになる*4

このことを行政機関の人達は理解していないのではなかろうか。なぜなら、 ベリサインの証明書は最も高価だからだ。マイナーな民間事業者にとっては、 価値あるブランドのコストであっても、行政機関にとっては、無価値なものに 不必要なコストを拠出していることになるのではないか?

加えて、行政機関が特定の民間事業者の独占化に加担しているという問題もあ るだろう。また、国内事業者の育成という観点でも、他の認証サービス事業者 も活用するべきではないのか。

Webブラウザの証明書ストアにルート認証機関として登録されている日本の会 社は、日本認証サービス社の一社 しか存在しない。しかも、日本認証サービスのルート証明書「Japan Certification Services, Inc., SecureSign RootCA1/2/3」は、Windowsには 入っているが、NetscapeやMozillaなどには入っていないため、いまひとつ使 いものにならないと言われている*5

現時点で政府が注力すべきことは、Webで使える民間認証局の育成ではなかろ うか。LGPKIで無理させるようなことを繰り返しているよりもだ。現時点では、 先に述べた「外国の認証局がわが国に対するサービスを停止してしまうおそれ」 に対して、「国内の認証局発行の証明書に切り替えて使う」という回避策が存 在しないのであり、ましてやそのとき民間事業者にLGPKIが証明書を発行して くれるはずもないわけで、このままでは安全保障上の問題が解決されていない ことになってしまう。

LGPKI Application CAに将来はあるのか

LGPKIが「まだ始まって間もない」ためにルート証明書が標準搭載されていな いだけで、将来は標準搭載されるというのであれば、LGPKIという仕組み自体 は間違いではなかろう。

と上で書いたが、では、LGPKIのApplication CAルート証明書が、Windowsや Webブラウザに標準搭載される日は本当にやってくるのだろうか。

まず、Windowsのルート証明書として搭載してもらうには、「WebTrust for CA」 という基準に従った監査を受けて合格することが必須となっている。その上で、 その認証局が十分に社会的価値を持つならば入れてもらえるということのよう だ。このことについては、Microsoft社の以下のページに説明されている。

Netscapeについても、聞くところによると、WebTrustの基準で搭載するかどう かを決めているのだそうだ。

WebTrust for CAについては以下のページなどが詳しい。

さて、LGPKIであるが、じつはLGPKIはちょっと一風変わった構成になっている。 まず、一般に認証機関(CA)は、登録機関(RA: Registration Authority)と 発行機関(IA: Issuing Authority)とに分割できるのだが、LGPKIでは、認証 局証明書が 1個しかないのに対し、各都道府県が RAの機能を持っている。つ まり、都道府県の権限で特定の地方公共団体に証明書を発行することを許可す るようになっている。

IAがどうなっているかは知らない。証明書を物理的に作成する作業が、どこで 行われているのか知らない。もし、都道府県がそれをやっているのだとすると、 LGPKI Application CAの秘密鍵が、各都道府県で管理されていることになる。

もしそうだとすると、すべての都道府県が Web Trust for CA基準の監査にパ スしないといけないことになるが、なんだか無理っぽい予感がする。また、 そもそも、そういった同一の認証局を共有して複数の場所で別々に管理するな どという形態の運用(なんだか危なっかしい気がする)が、Web Trust for CA 基準で認められているのだろうか?

あるいは、IAがどこかの共同施設で一括して行われているのだとすると、RAが 各都道府県で別々に行われることは、Web Trust for CA的にどうなのだろうか。 許されている運営形態なのだろうか。

もしそういった理由でLGPKIが、Web Trust for CA基準をクリアできないのだ とすると、LGPKI(のWebサーバ向けの利用*6)は完全に失敗作だったということになる。 その場合は、未来がないのだから、早急に使うのを止めてしまった方がよい。

もちろん、いずれにせよ「lg.jp」ドメインは活用した方がよい。 (10月27日の日記参照。)

*1 これが重要な何かを意味するのだろうか。

*2 強いて言えば、外国を信用しないと いう立場から、日本以外のルート認証局をすべて証明書ストアから削除してブ ラウザを使いたいという人にとっては、サーバ証明書が国産であることが必要 となるであろうが、そうするとそのブラウザは外国サイトへのアクセスでSSL を使えなくなるのであり、非現実的である。これはブラウザというソフトウェ アが、非常に汎用性の高い日常品であるという性質からやむを得ないことであ る。

*3 実際、私も、説明の便宜上「ベリサインなどの」という表現をせざるを得ない でいるし、埼玉県の担当者もそう言っていた。これは避けるべきだと思ってい る。

*4 閲覧者が認証 局まで目視確認して防衛している場合には、認証局の選択が重要になるという 反論が出るだろうが、最初の画面でいくら目視確認しても、次のページでなり すましされている可能性もあるのだから、すべてのアクセスを目視確認するこ とが現実的でない以上、やはりいずれにせよ偽の証明書に騙されることは防げ ない。(ブラウザの改良で防げるか?)

*5 Windows + IE の利用を強制するこ とになり、これはまた別の独占化の問題を起こす。

*6 LGPKIは、Webサーバ向けの 証明書発行だけではない。職責証明書なども提供しているのであり、そちらは 独自の方式のPKIなのだから閉じた世界で自由にやればよいわけで、それを否 定しているわけではない。

本日のTrackBacks(全100件) [TrackBack URL: http://takagi-hiromitsu.jp/diary/tb.rb/20050115]

FirefoxにLGPKIのルート証明書を組み込んでもらっては?

SSL対応の携帯電話の全てに対応するためにVeriSignの証明書を使っている可能性もあると思います。

 こんにちは、丸山満彦です。高木さん@自宅のブログでは、電子証明書の話が続いてい

某Oかやま県の対応だが、早々に Verisign に移行したようだ。業者は大手のH社系列会社のようであり、高木さんの日記は読んでいたのかもしれない。

Kyan's BLOG II:オレオレ証明書 (2005年10月24日 20:15)

スラッシュドット ジャパン | NTT西日本、問い合わせサイトのSSLが「オレオレ証明書」 すごくインパクトのある言葉が生まれていたんですね(苦笑)<オレオレ証明書 この言葉が生まれた経緯についてはこちらを参照。 高木浩光@自宅の日記 - 民間ブランドが行...

というわけで、高木浩光@自宅の日記を中心に糾弾されてきた GPKI/LGPKI のルート証明書配布問題 (LGPKI Application CAに将来はあるのか) が、ここに来てかなり改善されることになりました。 それにしても、今回のマイクロソフトの対応はちょっと驚きです。 通常の Windows..

検索

<前の日記(2005年01月14日) 次の日記(2005年01月20日)> 最新 編集

最近のタイトル

2024年11月11日

2024年07月28日

2024年07月27日

2024年07月07日

2024年04月07日

2024年04月01日

2024年03月23日

2024年03月19日

2024年03月16日

2024年03月13日

2024年03月11日

2023年03月27日

2022年12月30日

2022年12月25日

2022年06月09日

2022年04月01日

2022年01月19日

2021年12月26日

2021年10月06日

2021年08月23日

2021年07月12日

2020年09月14日

2020年08月01日

2019年10月05日

2019年08月03日

2019年07月08日

2019年06月25日

2019年06月09日

2019年05月19日

2019年05月12日

2019年03月19日

2019年03月16日

2019年03月09日

2019年03月07日

2019年02月19日

2019年02月11日

2018年12月26日

2018年10月31日

2018年06月17日

2018年06月10日

2018年05月19日

2018年05月04日

2018年03月07日

2017年12月29日

2017年10月29日

2017年10月22日

2017年07月22日

2017年06月04日

2017年05月13日

2017年05月05日

2017年04月08日

2017年03月10日

2017年03月05日

2017年02月18日

2017年01月08日

2017年01月04日

2016年12月30日

2016年12月04日

2016年11月29日

2016年11月23日

2016年11月05日

2016年10月25日

2016年10月10日

2016年08月23日

2016年07月23日

2016年07月16日

2016年07月02日

2016年06月12日

2016年06月03日

2016年04月23日

2016年04月06日

2016年03月27日

2016年03月14日

2016年03月06日

2016年02月24日

2016年02月20日

2016年02月11日

2016年02月05日

2016年01月31日

2015年12月12日

2015年12月06日

2015年11月23日

2015年11月21日

2015年11月07日

2015年10月20日

2015年07月02日

2015年06月14日

2015年03月15日

2015年03月10日

2015年03月08日

2015年01月05日

2014年12月27日

2014年11月12日

2014年09月07日

2014年07月18日

2014年04月23日

2014年04月22日

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|05|06|07|08|09|10|11|12|
2012|02|03|04|05|06|07|08|09|
2013|01|02|03|04|05|06|07|
2014|01|04|07|09|11|12|
2015|01|03|06|07|10|11|12|
2016|01|02|03|04|06|07|08|10|11|12|
2017|01|02|03|04|05|06|07|10|12|
2018|03|05|06|10|12|
2019|02|03|05|06|07|08|10|
2020|08|09|
2021|07|08|10|12|
2022|01|04|06|12|
2023|03|
2024|03|04|07|11|
<前の日記(2005年01月14日) 次の日記(2005年01月20日)> 最新 編集