電子申請を支える「電子認証」と 税務の専門家の役割 情報システム部夜間研修会 関東税理士会 川口支部 2005年6月2日 藤本一男 作新学院大学　人間文化学部　 fujimoto@sakushin-u.ac.jp　http://www.sakushin-u.ac.jp

お話の構成 インターネット時代の専門化集団の役割 電子文書と署名 認証局/署名の正当性は、なにが支えているのか。 認証局 暗号化の基本 共通鍵暗号方式と公開鍵暗号方式 電子署名 認証局/署名の正当性は、なにが支えているのか。 認証局 認証を実現する技術的信頼性と社会的信頼性。そして運用。 登録局（RA）本人確認。 2005/6/2 (c) Kazuo Fujimoto 2005

はじめに なぜ、「暗号」やら「認証局」やらといった、 ＩＴの知識を身に付けないといけないのか 電子化の流れは不可避（のようだ） 「上」から降りてくる方針を待っていていいのだろうか。（待っていることが、そもそも可能なのか。） 2005/6/2 (c) Kazuo Fujimoto 2005

あらゆるところにインターネット もはや、あることがあたりまえの社会インフラ。 民間企業のサービスはもちろん、国、自治体含めて、いわゆる「IT化」を推進。 問題も山積み システムへの侵入、情報の漏洩、等々 しかし、あまり語られてない領域もある。 2005/6/2 (c) Kazuo Fujimoto 2005

誰がメンバーを管理するのか 住基ネットをめぐった議論 地方自治とはなにかという問題。 自治体が住民の情報について責任をもつ。 のか 自治体が住民の情報について責任をもつ。 　　　　　　　　　　のか 自治体は、国家の窓口にすぎないのか。 地方自治とはなにかという問題。 住民データの入力機関としての自治体？ データの管理は、国家？ 1億2000万のデータの管理くらいなんでもない。 平成の大合併を支えるIT化 自治体経営の困難は、広域行政への道で、解決するのか。 2005/6/2 (c) Kazuo Fujimoto 2005

行政の電子化 そこで これらの「なぜ」に答えるために、 なぜ、財務省から降りてくる方針をまっていてはいけないのか。 なぜ、税理士会独自の認証局が必要なのか。 これらの「なぜ」に答えるために、 税理士の皆さんが「暗号」や「認証局」を理解する必要があるのです。 2005/6/2 (c) Kazuo Fujimoto 2005

電子政府における専門家の役割 e-Japan / e-Tax 流通業での中間過程の消失、改変 税理士は、どのような方針でいくのか 税務の専門家の役割 納税者の側にたった制度の提案 そもそも、国家は、専門家集団に方針を出せるのか。 （以上は、私の力量を超えた議論ですが） 2005/6/2 (c) Kazuo Fujimoto 2005

（異質な）三つの流れ インターネット コミュニティへの夢 アカデミックInternet コミュニティ・メディア これからの社会のデザイン 個人のパソコン利用 人口増大=市場 eビジネス/ 企業情報システム 業務の効率化 インターネットの 原理 行政業務の効率化 社会インフラの整備 行政情報システム e-Japan 正規分布ではなく、 べき乗分布!? 2005/6/2 (c) Kazuo Fujimoto 2005

情報システム(IS)とは 人的機構 機械的機構 IT（情報技術）しか見てないと、こうした視点が欠落する。 組織体または、社会の活動に必要な情報の収集、処理、伝達、利用に係わる仕組み 人的機構 機械的機構 IT（情報技術）しか見てないと、こうした視点が欠落する。 2005/6/2 (c) Kazuo Fujimoto 2005

狭義のISと広義のIS 人的機構 機械的機構 機械的機構 狭義の情報システム 広義のIS=情報システム 2005/6/2 (c) Kazuo Fujimoto 2005

ITは可視化します 情報システムは、なにか問題を解決するために導入されます。 ユーザが明確に定義されます。 既存のシステムのあらゆる部分を白日のもとに晒します。 業務内容 制度 選択するのは、そのシステムの利用者です。 2005/6/2 (c) Kazuo Fujimoto 2005

「電子のハンコ」とは言うものの 確かに、電子認証は、ハンコが実現してきた機能を電子的に実現する。 しかし、ハンコの機能を電子化したものではない。 暗号技術が可能にした「電子署名」の機能を従来からのハンコにみたてて活用しよう、ということでしかない。 置き換えられない領域がでてあたりまえ。 2005/6/2 (c) Kazuo Fujimoto 2005

電子署名・電子認証を支える 「暗号技術」を理解しましょう 電子申請は、暗号技術とその技術に支えられた制度「電子署名法」によって可能になっています。ここでは、この一般的なからくりを理解しておきます。

サイバースペースに「形」を与えるもの：暗号 コンピュター、インターネットの世界 Bitで構成されている これまでの前提を自明のものにできない コピーが自由：電子データ 正本と複写に区別なし。改竄も簡単。 匿名の世界 本人同一性の確認が難しい サイバースペースに「形」を与えるもの：暗号 2005/6/2 (c) Kazuo Fujimoto 2005

ネットワーク上の危険性 電子データの柔軟さの表裏の関係 この問題を「暗号」が解決する。 覗き見される 改竄される 成りすましをされる 送った内容を知らない、といわれる この問題を「暗号」が解決する。 2005/6/2 (c) Kazuo Fujimoto 2005

電子文書とはなにもの？ 文書の電子化:ファイルという単位 文字の電子化：文字コードと制御コード 文字コード 文字をある順番に並べた表があって、それぞれの文字に番号がついている。 何番の文字は何、という約束が「文字コード表」 JIS、EUC、Unicode、など 一見、暗号っぽいが、これは国際規格で決まっているので、パソコンならずとも、誰でも読める。（次ページ参照） 2005/6/2 (c) Kazuo Fujimoto 2005

文字コード* あ 82A0 (33440) い 82A2 (33442) う 82A4 (33444) え 82A6 (33446) : * 16進数で表記 1 2 : 9 A(10) B(11) C(12) F(15) 2005/6/2 (c) Kazuo Fujimoto 2005

82A0という「数字」をコンピュターは「あ」と表示する 改行 82A0という「数字」をコンピュターは「あ」と表示する い A 2005/6/2 (c) Kazuo Fujimoto 2005

電子文書 この文字コード、改行などの制御コードを要素。 「ファイル」という単位で、「文書」が構成されている。 ここで説明につかったのは、Plainテキストと呼ばれるもっとも単純な構成（文字と改行）。 ワープロの文書データは、これに文字修飾、書式データなどなどが加わり複雑なものになっている。 電子メールの基本は、このPlainテキスト。 これらは、すべて「数」として扱える。つまり計算の対象。 暗号化とは、数学的な計算をこの文書に施すこと。 2005/6/2 (c) Kazuo Fujimoto 2005

暗号入門 共通鍵方式 共通鍵方式の問題点 公開鍵方式 アルゴリズムと鍵 鍵配送問題 複数の相手との通信 共通鍵方式の問題を解決 あわせて、「電子署名」を実現した。 2005/6/2 (c) Kazuo Fujimoto 2005

暗号のアルゴリズムと鍵 たとえば シーザー暗号 アルゴリズム（方式） 鍵 ABCDEFG.….XYZ を二文字ずらすと、 アルゴリズム（方式）　 アルファベットをずらす 鍵 ずらす文字数 シーザー暗号 ABCDEFG.….XYZ　を二文字ずらすと、 CDEFGHI.……ZAB 暗号化：文字コード（番号）に2を加える 複号化：2を引いて文字コードとして読む 26文字なので、26を法とする演算で計算できる。 y = (x + 2)mod 26　　　(x+2を26で割った余りがy) 2005/6/2 (c) Kazuo Fujimoto 2005

暗号化 複号化 Rot13は、「13文字 ずらす」。暗号化と 複号化が同じ処理 ずらす：アルゴリズム 13：鍵 2005/6/2 (c) Kazuo Fujimoto 2005

暗号通信 13文字戻す 13文字先にずらす I LOVE YOU V YBIR LBH I LOVE YOU 2005/6/2 (c) Kazuo Fujimoto 2005

共通鍵方式 ここで暗号と複号には、（同じアルゴリズムで）同じ鍵が使われる。 つまり、同じ鍵をもっているもの同士でしか暗号通信できない。 2005/6/2 (c) Kazuo Fujimoto 2005

鍵配送問題 同じ鍵を使い続け るのは危険 では、鍵を安全に 配送するにはどう したらいいだろうか。 鍵を安全に渡せるならメッセージを 渡せばいいではないか…。 2005/6/2 (c) Kazuo Fujimoto 2005

なんだ、他の 人のメッセージ が見える じゃないか。 ということは... 多数の相手との通信での困難 同じ鍵を使ったら、他人に見られてしまう。 相手ごとに別の鍵が必要になる。 あんたのも 読めるよ～ なんだ、他の 人のメッセージ が見える じゃないか。 ということは... 2005/6/2 (c) Kazuo Fujimoto 2005

N人が相互に暗号通信するには N(N-1)/2 個の異なった鍵が必要 不特定多数の人から暗号メッセージをもらうことは無理 2005/6/2 (c) Kazuo Fujimoto 2005

公開鍵方式の登場* 共通鍵方式の以上の問題点を解決 加えて、「電子署名」を可能にした。 1970年代 Diffie と Hellman Rivest, Shamir, Adleman (RSA) 二つの鍵の組み合わせで、暗号、複号を実現する。 * 自分で計算しながら確かめることも不可能ではありません。文献を参考にしてください。 2005/6/2 (c) Kazuo Fujimoto 2005

鍵ペア こんな機能をもった鍵のペアが作れる、ということ。 受信者の鍵Aがつくられる。 この鍵Aに対応した鍵Bが作られる（AとBは同時にできる）。 鍵Aで暗号化したものは、鍵Bでしか複号できない。 鍵Aは、公開され、鍵Bは、受信者だけが知っている。 鍵Aから鍵Bの生成は、他の人には、著しく困難。 2005/6/2 (c) Kazuo Fujimoto 2005

暗号化/復号化の仕組み 送り手が、相手の「公開鍵」を入手＊ 相手の「公開鍵」でメッセージを暗号化 送信 受信した方は、自分の「秘密鍵」で、メッセージを復号化する。 ＊公開鍵は、メール渡し、Web公開、認証局が証明書で配布、などいろいろな方法で渡される 2005/6/2 (c) Kazuo Fujimoto 2005

暗号送信者 花子さんの公開鍵 暗号受信者 手紙 手紙 太郎さん 花子さん 花子さんの秘密鍵 ???? 危険な インターネット 暗号化 太郎さん 花子さん 太郎さんは、 花子さんの 公開鍵で暗号化する こうして暗号化された ものは、太郎さんも 読めない。 hIwDYQYx9 Y2CvL0BBA C7AXMir 花子さんの秘密鍵 復号化 花子さんは 自分の秘密鍵で暗号 化されたメッセージを 復号化する。 hIwDYQYx9Y2CvL0BBA C7AXMir hIwDYQYx9 Y2CvL0BBA C7AXMir ???? 危険な インターネット 暗号の基本形　その１ 2005/6/2 (c) Kazuo Fujimoto 2005

実際には....。 公開鍵方式は、処理の負荷（計算の量）が共通鍵方式よりも大きい（遅くなる）。 本文は、共通鍵で暗号化。 暗号の基本形　その２ 実際には....。 公開鍵方式は、処理の負荷（計算の量）が共通鍵方式よりも大きい（遅くなる）。 本文は、共通鍵で暗号化。 その共通鍵を、受信者の公開鍵で暗号化して送る。 受信者は、自分の秘密鍵で、共通鍵をとりだし、メッセージ本文を復号する。 （これらは、自動的に行われる。メールの例を。） 2005/6/2 (c) Kazuo Fujimoto 2005

2005/6/2 (c) Kazuo Fujimoto 2005

さて、次は、電子署名です。

デジタル署名とは、....ではない。 2005/6/2 (c) Kazuo Fujimoto 2005

電子署名（という暗号化）の仕組み 自分の「秘密鍵」で、メッセージを暗号化して送信 受信者は、送信者の「公開鍵」を入手 送られてきたメッセージをこの「公開鍵」で復号化。 復号できれば、このメッセージは、入手した公開鍵に対応する秘密鍵を持っている人が暗号化した（署名した）ことを意味する。 実際は、メッセージダイジェストを用いる（後述） 2005/6/2 (c) Kazuo Fujimoto 2005

こういう暗号化を 「署名」と呼ぶ。 署名者 太郎さんの公開鍵 検証者 手紙 手紙 太郎さん 花子さん 太郎さんの 秘密鍵 ???? encryption 太郎さん 花子さん hIwDYQYx9 Y2CvL0BBA C7AXMir decryption 太郎さんの 秘密鍵 太郎さんの公開鍵でメッセージ が復号できた、ということとは、 このメッセージを暗号化したのは、 公開鍵に対応した秘密鍵を持っ ている「太郎さん」に他ならない、 という関係。 こういう暗号化を 「署名」と呼ぶ。 hIwDYQYx9Y2CvL0BBA C7AXMir hIwDYQYx9 Y2CvL0BBA C7AXMir ???? 危険な インターネット 2005/6/2 (c) Kazuo Fujimoto 2005

メッセージ・ダイジェスト MD5(32)、SHA(40)、など どのような大きさのファイルからも、一定バイトの出力を生成。 例）MD5で、24Byte、108KByteを計算。出力は、32Byte(256ｂｉｔ)。2の128乗（10の77乗） パスワード 照合も、MD の比較で行 われる。 2005/6/2 (c) Kazuo Fujimoto 2005

メッセージダイジェスト 数バイトの ファイル 数メガの ファイル Message Digest 関数 出力は、40byte（sha） 逆は、不可能 da39a3ee5e6b4b0d3255bfef95601890afd80709 da39a3ee5e6b4b0d3255bfef95601890afd80709 2005/6/2 (c) Kazuo Fujimoto 2005

署名者 太郎さんの公開鍵 手紙 検証者 手紙 太郎さん 花子さん 太郎さんの 秘密鍵 一致？ 危険な インターネット encryption MDが一致してれば、 太郎さんが書いたまま 。改竄も検出 署名者 太郎さんの公開鍵 Message Digest 手紙 hLsRYS4rm8B/sy 検証者 手紙 encryption 太郎さん これが署名 花子さん 手紙 GIKV3ioy1wHP 太郎さんの 秘密鍵 Decryption 署名を復号し、MDを得る 一致？ hLsRYS4rm8B/sy hLsRYS4rm8B/sy 改竄：書き換えてしまえ！ 手紙のMessage Digest を計算 手紙 GIKV3ioy1wHP 危険な インターネット 太郎さんの公開鍵で復号したMDと、 本文から計算したMDが等しければ、 そのメッセージは、太郎さんの秘密鍵 でそのメッセージは署名されている、 ということ。 2005/6/2 (c) Kazuo Fujimoto 2005

JPCERT/CC コンピュタ－緊急 対応センター この部分に対す るMDを、 JPCERTの秘密 鍵で暗号化した ものがこれ。 検証には、 http://www.jpcert.or.jp この部分に対す るMDを、 JPCERTの秘密 鍵で暗号化した ものがこれ。 検証には、 JPCERT公開鍵 を用いる。 Web参照 2005/6/2 (c) Kazuo Fujimoto 2005

共通鍵の二つの困難を解決 鍵配布と、N人から独立に暗号文を受信。 公開鍵 秘密鍵 読めるのは、「秘密鍵」の持ち主だけ 2005/6/2 (c) Kazuo Fujimoto 2005

公開鍵暗号で対処するもの 覗き見 暗号化 改竄 電子署名 なりすまし 電子署名 否認（しらばっくれ） 電子署名 覗き見 暗号化 改竄 電子署名 なりすまし 電子署名 否認（しらばっくれ） 電子署名 しかし、「署名」が正しく本人であることの証明には、「公開鍵」と本人の結びつきの社会的証明が必要。認証局の役割。 2005/6/2 (c) Kazuo Fujimoto 2005

ちょっと整理しておきます デジタル署名 Digital Signature 証明書 Certificate 自分の秘密鍵で暗号化すること（MDを暗号化）。 Cf　電子署名　Electronic Signature 電子メールにつける署名部分を呼ぶこともある。こちらには、認証機能はない。 証明書 Certificate 電子署名に使われた暗号鍵が利用者のものであることを証明する。(政府の解説) ある人の公開鍵を登録者の属性とともに保証するもの。証明書の発行者の署名もされている。 2005/6/2 (c) Kazuo Fujimoto 2005

電子署名法 第２条（定義） この法律において「電子署名」とは、電磁的記録（電子的方式、磁気的方式その他人の知覚によっては認識することができない方式で作られる記録であって、電子計算機による情報処理の用に供されるものをいう。以下同じ。）に記録することができる情報について行われる措置であって、次の要件のいずれにも該当するものをいう。 当該情報が当該措置を行った者の作成に係るものであることを示すためのものであること。 当該情報について改変が行われていないかどうかを確認することができるものであること。 2005/6/2 (c) Kazuo Fujimoto 2005

では、この技術を使えば すべてよし、か 電子署名を実現する公開鍵暗号方式の理論は、すばらしい。 なら、この方式を正しく実装すれば、問題は解決。安全なネットワーク社会ができるのだろうか。 実は、問題はここから始まります。 2005/6/2 (c) Kazuo Fujimoto 2005

その前に、小テスト これは、「SoftwareDesign」という技術専門雑誌の書籍紹介の記事です。専門書のライターさんでも、こんな間違いをおかしています。 これまでの理解を整理するために、やってみてください。 2005/6/2 (c) Kazuo Fujimoto 2005

電子署名の信頼性はなにに支えられているのだろうか。 これまで見てきた電子署名の仕組みは多くの前提をもとに単純化しています。ここからは、その前提を考えていきます。

復習として..暗号と署名 暗号は、二者関係 署名は、三者関係、つまり「社会」を前提にしている。 当事者間の閉じた世界 ルールがある場での決着は、当事者ではなく、第三者（例：審判、判事）が行う。 では、署名の保証は誰がするのか。 2005/6/2 (c) Kazuo Fujimoto 2005

対立！ 審判、判事、ルールを体現 第三者が判定 そんな約束 あんたの署名 してない があるよ。 あながた 正しい！ 2005/6/2 (c) Kazuo Fujimoto 2005

「電子署名」を支える認証局 証明書の署名は信用できるのか どこまでさかのぼるのか。（さかのぼれるのか） 太郎さんの登録 の際の本人確認 はどうするのだろう 証明書に対する署名 この証明書についている 公開鍵は、太郎さんのもの であることを証明します。 花子 公開鍵 太郎さん 証明書 証明書の署名は信用できるのか どこまでさかのぼるのか。（さかのぼれるのか） X.509 認証局 鍵は一個？ PCは複数。 ならスマートカードか 秘密鍵 2005/6/2 (c) Kazuo Fujimoto 2005

署名の正当性 公開鍵をどのような形で（誰の署名をつけて）公開するのか。 ここで成りすまされたら､もともこもない。 公開鍵の正当性を保証するのは、社会的信用。 鍵への署名 認証局の重要性。 登録の際の本人確認の信頼性（入り口はしっかりしているか。） 鍵の管理：発行、停止、更新、無効、破棄（有効な鍵か？） 認証局の正当性（正しい認証局サーバーか？） 2005/6/2 (c) Kazuo Fujimoto 2005

PKIとは、 利用者が自分の秘密鍵を正しく運用（管理、使用）し、 認証局が、その利用者と利用者の公開鍵を正しくむすびつけていれば、 正しく機能し、 利用者が、その情報行為の主体でありつづけることが可能な システム 2005/6/2 (c) Kazuo Fujimoto 2005

認証局の正しさと秘密鍵の利用/管理が正しいこと 認証局が「正しく」（公開鍵と 本人の関係）、秘密鍵が本人 に管理されていればシステム が「正しい」と判定することは、 社会的にも正しい。 署名/検証行為 秘密鍵の管理 認証局の正しさ 秘 公 暗号理論/Public Key 2005/6/2 (c) Kazuo Fujimoto 2005

信用モデル 直接的な信用(Direct Trust) 階層的信用(Hierarchical Trust) 公開鍵を本人から受け取った 階層的信用(Hierarchical Trust)　 社員証認証局。法定認証局 どこかに「原点」 信用の輪(A Web of Trust) PGPが採用している、友達の友達は、まあ、友達。 一人一人が、認証局 2005/6/2 (c) Kazuo Fujimoto 2005

認証局の階層構造 CA１~３の「正しさ」は、CA0が保証する。 では、CA0の正しさは、誰が保証するのか。 …. 2005/6/2 (c) Kazuo Fujimoto 2005

二つの極端な形態 一つのルートが信用のルートとなる 社会を個人の集合とみて、個人が認証局となる。 国家？（国際的ルート？） 絶対神？（御名御璽サーバー？） 社会を個人の集合とみて、個人が認証局となる。 PGP(PretyGoodPrivacy)というソフトで実現されている。 2005/6/2 (c) Kazuo Fujimoto 2005

PKIは、正しさを増幅 するわけではない 形式論理を例に、「正しさ」について考えてみる。 三段論法の正しさは、この推論過程の正しさ。 P　→ Q　（PならばQである） Q　→　R　（QならばRである） Pである。よって、Rである。 三段論法の正しさは、この推論過程の正しさ。 「Pである」ことが正しいかどうかとは別に、この「正しさ」を主張することができる。 PKIの正しさは、こういうこと。 では、「Pである」ことが正しいためには…。 2005/6/2 (c) Kazuo Fujimoto 2005

認証局はコミュニティが維持すべき 認証局が正しく機能するためには これは、文字通り「会員管理」 どこがやるのか 登録の時点で、正しい本人確認がされること 登録内容の変化（変更、失効、停止、など）に対応して発行証明書の有効性を反映できること。 これは、文字通り「会員管理」 どこがやるのか 日税連しかない 実際の運用管理は、各支部以外に担うことは不可能。 2005/6/2 (c) Kazuo Fujimoto 2005

ネットワークは、平等を増幅するか インターネットへの期待 しかし、現実は異なるらしい 集中へ！ だれでも平等に参加する機会をあたえる 公正な社会を実現するインフラになる！ しかし、現実は異なるらしい 平等化原理（正規分布）ではなく、極端化原理こそが社会の本性（べき乗分布） インターネットにおいても、それが鮮明に現れている。 公文俊平『情報社会学序説』NTT出版,2004 集中へ！ 2005/6/2 (c) Kazuo Fujimoto 2005

専門家集団の要件 専門的な職能を有していること 自律性 公式な組織 倫理綱領の存在 メンバーの管理 公式な組織 倫理綱領の存在 社会的機能 デボラ・ジョンソン「第三章 専門家倫理」『コンピュータ倫理学』p89-90 2005/6/2 (c) Kazuo Fujimoto 2005

まとめ 独自認証局を維持するということが、IT社会での専門家集団として存在するための必要条件 技術的な領域は、認証局の運用の一部。会員管理、利用者教育、実際の利用・管理、のノウハウは、組織運営の領域。誰かが作ってくれるわけではない。 IT時代の専門家集団へ 2005/6/2 (c) Kazuo Fujimoto 2005

参考文献 辻井重男『暗号と情報社会』文春文庫078、1999 佐々木良一『インターネットセキュリティ入門』岩波新書606、1999 岡村久道『電子署名法の解説』http://www.law.co.jp/OKAMURA/jyouhou/e-sign.htm ローレンス・レッシグ『CODE　インターネットの合法・違法・プライバシー』翔泳社、2001 ルドルフ・キッペンハーン『暗号攻防史』文春文庫2001 藤本一男「認証要素と認証関係からPKIを考える」『サイバーセキュリティマネジメント』2005/6,ppxx-xx 藤本一男「Pythonで実験しながら学ぶ暗号理論」 2005/6/2 (c) Kazuo Fujimoto 2005

付録

IT社会ではCODEが法になる† ある情報システムが導入されることで、制度が規定される。 なし崩し的な「法改正」が行われる可能性がある。 誰が、なんのために？ †ローレンスレッシグ『CODE』 2005/6/2 (c) Kazuo Fujimoto 2005

仕組みはエレガントなのになぜ、不安になるのか 理論的な美しさ 現実には、ここにさまざまな 危さが潜んでいる。 署名/検証行為 この部分の頑丈さ ←暗号理論 暗号理論/Public Key 2005/6/2 (c) Kazuo Fujimoto 2005

雲の中にはなにがあるのか ハード、ソフト、ネットワーク、運用管理… 署名/検証行為 暗号理論/Public Key 2005/6/2 (c) Kazuo Fujimoto 2005

ソフト/ハード/ネットワークは、正しく動くように保守されているか。運用は正しい 署名/検証行為 インターフェース CP/CPS ソフト/ハード/ネットワークは、正しく動くように保守されているか。運用は正しい ソフトウェア ハードウェア ネットワーク 運用管理 バグは ないか 暗号理論/Public Key 暗号理論は、安全か 2005/6/2 (c) Kazuo Fujimoto 2005

署名/検証行為 インターフェース CP/CPS インターネット OS 暗号理論/Public Key 検証、ってなにを検証している？ その証明書、なんで正しいと思う？ 署名/検証行為 画面の中の世界を信じてる？ インターフェース CP/CPS 「署名」って何時した？ その認証局、なにもの？ インターネット OS ここは、OKだと しようか（実際は、議論すべきことがたくさんあるが）。 暗号理論/Public Key 2005/6/2 (c) Kazuo Fujimoto 2005

電子署名・認証法 階層的認証を考えている。 では、誰がなにを認証するのか。 元締め、があるということ。それはなに、誰？ Webサーバーの証明書の取得には、会社の登記簿謄本と社印が必要。 では、登記簿の単なる電子版でしかないのだろうか。 個人の場合はどうなるのだろうか。 2005/6/2 (c) Kazuo Fujimoto 2005

PKI vs ID,パスワード ある利用者を確認するのに、なぜ、ID、パスワード方式ではだめか。 IDパスワードは、サーバの管理者が「正しい人」であることを求める。PKIは、利用者がすべてを管理。 2005/6/2 (c) Kazuo Fujimoto 2005