セキュリティ

INPUT · スライド

本人であることの証明

01 / 12

隠すことと、確かめることは別

暗号で中身を隠せば安心、とはいかない。通信を守るには、じつは3つの別の問いに答える必要があるんだ。

  • 中身を他人に読まれないか … これが暗号の仕事
  • 途中で書きかえられていないか … これを 改ざん検知 という
  • 本当にその人が書いたのか … これを 認証 という

このレッスンは、下の2つを扱うよ。中身を隠す話ではないので、暗号は出てくるけれど目的が違うという感覚をつかんでほしい。

試験でも「暗号化」と「署名」を混ぜた選択肢が必ず並ぶ。そこで迷わないための回だよ。

02 / 12

本文の指紋 ― メッセージダイジェスト

改ざんされていないことを確かめるには、本文をまるごと見比べればいい。でも長い文書でそれをやるのは重い。

そこで使うのが メッセージダイジェスト だよ。本文をハッシュ関数に通して出てくる短い値で、本文の指紋のようなもの。ハッシュ値 とも呼ぶ。

性質は2つ。本文が1文字でも変わると、まるで違う値になる。そして長さはいつも同じ。だから元の文書が10文字でも10万文字でも、指紋は同じ大きさになる。

この指紋を照らし合わせれば、本文を全部見比べなくても書きかえの有無が分かるんだ。

本文 → ダイジェスト「おはよう」 → 3f9a1c...「おはよぅ」 → b72e08...1文字違うだけで別物

03 / 12

ディジタル署名の作り方

指紋だけを送っても、指紋ごと差しかえられたら意味がない。指紋に本人のはんこを押す必要がある。それが ディジタル署名 だよ。

送る側の手順はこう。

  • 本文からメッセージダイジェストを作る
  • そのダイジェストを自分の秘密鍵で変換する
  • できたものが署名。本文にくっつけて送る

秘密鍵は本人しか持っていない。だからこの署名を作れるのは本人だけになる。ここが「はんこ」として働く理由だよ。

署名するのは本文ぜんたいではなくダイジェストだという点も押さえておこう。短い値だけを処理するから軽いんだ。

送る側本文 → ダイジェスト     → 秘密鍵で変換     → 署名本文 + 署名 を送る

04 / 12

検証は送信者の公開鍵で

受け取った側は、署名を送信者の公開鍵で元に戻す。出てくるのはダイジェストだよ。

それと、手元の本文から自分で計算したダイジェストを見比べる。一致すれば合格

一致したときに分かることは2つある。本文が書きかえられていないこと(指紋が合っている)、そして送信者本人が署名したこと(その公開鍵で開けたのだから、対になる秘密鍵の持ち主が作った)。

ここで鍵の使い方に注意。中身を隠すときと向きが逆なんだ。表にすると迷わなくなるよ。

暗号化 受信者の公開鍵で包む       受信者の秘密鍵で開く署名   送信者の秘密鍵で作る       送信者の公開鍵で確認

05 / 12

署名で分かること・分からないこと

ここが試験でいちばん狙われるところ。署名は中身を隠さない。本文はそのまま添えて送っているのだから、のぞき見られたら読めてしまうよ。

署名で言えるのは次の3つだけ。

  • 本文が改ざんされていないこと
  • だれが作ったのかということ
  • 本人が「書いていない」と言い逃れできないこと(否認防止

逆に、次のことは言えない。内容が第三者に漏れないこと、確かに届くこと、その人に何かの資格や許可があること、同じものが再送されていないこと。

選択肢にこれらがもっともらしく並ぶので、「隠す」「届ける」「許可する」は署名の仕事ではないと覚えておこう。

06 / 12

公開鍵の身分証 ― 証明書と認証局

署名の検証には送信者の公開鍵が要る。でも、受け取った公開鍵が本人のものだと、どうして言えるのか。にせ者が自分の公開鍵を「私が本人です」と配ってしまえば、署名も検証も通ってしまう。

この穴をふさぐのが 公開鍵証明書(ディジタル証明書)だよ。「この公開鍵はこの人のものです」と書いた身分証で、持ち主の名前・持ち主の公開鍵・有効期限に加えて、発行元のディジタル署名が入っている。最後の1つが肝で、証明書が偽物なら検証で落ちる

発行するのが 認証局CA)。当事者のどちらでもない信頼できる第三者という立場で保証する。証明書と認証局を組み合わせた仕組み全体を PKI(公開鍵基盤)と呼ぶよ。

認証局の仕事は証明書を発行することだけ。似ているけれど別物の仕事が選択肢に並ぶので、切り分けておこう。

  • 正確な時刻を配る … 時刻認証局(タイムスタンプ)の仕事
  • 利用者のメールに代わりに署名を押す … 認証局はしない
  • 秘密鍵やパスワードを預かる … 認証局はしない
証明書の中身・持ち主の名前・持ち主の公開鍵・有効期限・発行元のディジタル署名

07 / 12

HTTPS のサーバ証明書

毎日使っている身近な証明書がこれ。ブラウザのアドレス欄に出る鍵のマークだよ。

https:// でつなぐと、サーバは自分の サーバ証明書 をブラウザに見せる。ブラウザは中の署名を認証局の公開鍵で検証して、つなぎに行った相手が名乗っているそのサーバかを確かめる。これが http:// にはない働きだよ。

もうひとつ、サーバとブラウザの間の通信を暗号化するのも HTTPS の仕事。この2つがまとめて https:// の中身だ。

逆に、HTTPS がやらないこともはっきりさせておこう。サーバに送りこまれる不正な入力を止めたり、通してよい通信を選り分けたりはしない。運ぶ途中を守る仕組みであって、着いたあとの入口を守る仕組みではないんだ。

https がするのは2つ・相手が本物かの確認・通信の暗号化入口の守りは別の仕組み

08 / 12

証明書は機械にも入れられる

証明書を持つのはサーバだけじゃない。つないでくる側の端末に入れることもできて、これを クライアント証明書 と呼ぶよ。

会社のスマートフォンに証明書を入れておくと、社内システムは接続してきた端末の証明書を検証して、あらかじめ許可した機械かどうかを確かめられる。持ち込みの私物ではじかれる、という使い方だね。

注意したいのは、分かるのはその1点だけということ。証明書を入れても、その端末がウイルスに感染していないか、OS の更新が当たっているか、アプリが最新かはまったく分からない

証明書は身分証であって健康診断書ではない、と考えると混ざらないよ。

09 / 12

人を確かめる3つの要素

ここまでは機械やデータの話。ここからはを確かめる 利用者認証 だよ。

手口は要素として3つに分けられる。

  • 知識(本人だけが知っていること)… パスワード、PIN、秘密の質問
  • 所持(本人だけが持っているもの)… IC カード、ハードウェアトークン、スマートフォン
  • 生体(本人の体そのもの)… 指紋、虹彩、静脈、顔

どれも弱点がある。知識は忘れるし推測される。所持は落とす。生体は取り替えられない。だから複数を組み合わせるのが基本になるよ。

知識 パスワード・PIN所持 IC カード・トークン生体 指紋・虹彩・静脈

10 / 12

多要素認証とワンタイムパスワード

2つ以上を組み合わせるのが 多要素認証。2つなら 2要素認証 だよ。

大事なのは、違う要素どうしを組み合わせないと意味がないこと。パスワードと秘密の質問はどちらも「知識」なので、2つ並べても1要素のまま。指紋と静脈もどちらも「生体」だから同じだよ。パスワード(知識)+静脈(生体)なら、これは2要素。

もうひとつよく出るのが ワンタイムパスワード1回だけ使える使い捨ての値で、盗み見られても次には使えない。時刻から作る方式と、サーバから届いた値に答えを返すチャレンジレスポンス方式があるよ。

IC カードと PIN の組み合わせも所持+知識で2要素。運用では、PIN はカードと同じ封筒に入れない(別経路で伝える)、紛失したら先に失効させてから作り直す全員に同じ PIN を配らないが基本だよ。

11 / 12

生体認証の2つの率

生体認証は「合っている/いない」をきっぱり決められない。指紋の読み取りは毎回わずかに違うので、どこまで似ていれば本人とみなすかという線引きが要るんだ。

そこで2つの率が出てくるよ。

  • 本人拒否率 … 本人なのに誤って拒否してしまう割合
  • 他人受入率 … 他人なのに誤って通してしまう割合

この2つは同時に下げられない。判定をゆるくすれば本人は通りやすくなるが、他人も通ってしまう。きつくすれば他人は止まるが、本人もはじかれる。

だから装置を入れるときは、両方を見比べて線を決めることになる。「どちらか一方を下げる」と書いてある選択肢は誤りだよ。

ゆるくすると  本人拒否率 ↓  他人受入率 ↑きつくすると  本人拒否率 ↑  他人受入率 ↓

12 / 12

通したあとの話 ― アクセス制御

認証が済んでも、まだ終わりじゃない。だれかが分かっただけで、何をしてよいかは別に決めないといけない。それが アクセス制御 だよ。

  • 認証 … だれなのかを確かめる
  • 認可 … 何をしてよいかを決める

何をしてよいかの一覧が アクセス権。データベースなら「参照だけ」「登録や変更もできる」「表そのものを作り替えられる」のように段があるよ。

配り方の原則は 最小権限その仕事に必要な最小限だけを与える。検索して表示するだけのアプリなら参照権限だけで足り、更新権限や管理者権限は渡さない。多めに渡しておけば楽だけれど、乗っ取られたときの被害がそのぶん大きくなるんだ。

人ごとではなく役割ごとに権限をまとめるのも定番。担当が変わっても付け替えが1回で済むよ。

認証 → だれなのか認可 → 何をしてよいか参照だけの機能  → 参照権限だけ