10. セキュリティ
https://gyazo.com/b613461e4759af40dcbd1950a5f0a4d3
Twitter乗っ取り事件
https://gyazo.com/4fd4b80773fe58d40b65bbad5daeb82e
使いやすさとセキュリティ
だいたい両立しない
重要なのに研究が人気がない
システム/人間を総合的にセキュリティを考える
重要概念だが流行っていない
必要技術
人が安心できる方式
安全性を評価する技術
https://gyazo.com/a082e9d54a3f2e778c516bb82c47a376.png
情報セキュリティ心理学とトラスト研究会
心理学な面からセキュリティを考える
2011年から活動
会員少ない
セキュリティ研究
暗号とか攻撃とか脆弱性とか
社会における様々な機能がインターネットやそこに接続された無数のコンピュータによって制御され、運用管理が行われるようになった現在、ネットワークで接続されたサイバースペースの安全は今後の社会を支えていく上でますます重要なものとなっている。日々様々な形の犯罪や事故が発生しておりこういった事態を未然に防止し被害を最小に止めるサイバーセキュリティの専門家に対するニーズが高まっている。セキュリティ専門家は情報技術やネットワークの技術的な知識だけでなく、法律、社会制度、組織の運営管理など学際的で総合的な知識に加えサイバー攻撃やシステム脆弱性の分析、事件・事故への迅速な対処などセキュリティ領域における深い理解と高度な対処能力も求められる。本コースでは、 SFCの学際性と情報通信分野における高度な専門性を活かして社会の要請に応える高度なサイバーセキュリティ人材を育成する。
サイバーリーダーシップ
https://gyazo.com/52014c00ff1fa1871055ae1bd7be3838
正しい認証とは?
http://www.mneme.co.jp/data/images/thesis3_1.gif
http://www.mneme.co.jp/data/images/thesis3_2.gif
Security visualizaton
https://www.amazon.co.jp/dp/0321510100 https://gyazo.com/7aedb3bff6f9ce6ecb04ff6ab23b32af
認証の必要性
ユビキタス社会
→ 誰もがどこでも計算機を使う
→ 計算機資源の共有がすすむ
→ どこでも認証が必要になる
認証のいろいろ
持っているものを利用
鍵、USB
自分自身の特徴を利用
生体認証
知っているものを利用
パスワード, チャレンジ質問
能力を利用
CAPTCHA
組み合わせ
銀行カード+暗証番号
二段階認証
生体認証+暗証番号?
Webページの認証
現在はパスワードベースがほとんど
それ以外(画像認証など)は導入進まず
パスワード認証
実装が割と簡単
認識技術が不要
パソコンで利用しやすい
キーボードがあるから
正しく運用すれば安全
いくらでも強力にできる
パスワードの問題点
適切なパスワードを選ぶのが困難
覚えるのに苦労する
すぐ忘れる
容易に解読される
安全な運用が難しい
簡単にコピー可能
文字入力装置が必要
認証ハードウェアの問題点
持ち歩くのが邪魔
持ち歩くのを忘れる
紛失/盗難の危険
生体認証の問題点
怪我や病気で使えなくなる
コピーされる可能性がある
気絶させて盗める
変更が不可能
様々な認証
パスワードが一番マシ?
http://gyazz.com/upload/be36ee9a3c80239387aea5e5776de6f5.pdf https://gyazo.com/dae200eef4281fe3b8e4f8dc6c9b44b9.png
パスワードの運用方法
使い回しは厳禁
https://gyazo.com/4f1e7b5e4442fb9e71683c859632ccde
パスワードの運用方法
定期変更の強制は危険
変なものを設定しがちだから
自発的に変更するのはOK
紙に書いてしまっておくのが良いらしい
パスワードが漏れているかのチェック
Chrome拡張
漏れているパスワードを登録しようとすると怒られる
チェック例
ブラウザの認証
Basic認証
Digest認証
自力で認証
Basic認証のやりかた (Apache)
.htaccessというファイルに記述
code:.htaccess
AuthUserFile /home/masui/.htpasswd
AuthGroupFile /dev/null
AuthName "Password Required"
AuthType Basic
require user masui
パスワードファイルはhtpasswdコマンドで生成
平文でパスワードが流れる
.htaccessに記述
code:.htaccess
AuthType Digest
AuthName "member only"
AuthDigestDomain /server/script/digest/
AuthDigestFile /home/masui/.htdigest
require user masui
パスワードファイルはhtdigestコマンドで生成
サーバから渡されたIDをもとに暗号化
自力で認証する例
code:html
<center>
<input type="password" style="font-size:30pt;"><br>
<span style="font-size:24pt;"><input type="password" style="font-size:20pt;"></span>
</center>
HTTPSで通信
覗き見防止
パスワードのハッシュをサーバに記憶
流出防止
認証の継続
ログイン状態をどうやって継続するか
Cookieの利用が一般的
認証中を示す情報をサーバがブラウザに送る
ブラウザは認証が継続していることを毎回サーバに知らせる
Web上の証明機構
PKI (Public Key Infrastructure)
PGP (Pretty Good Privacy)
c.f. 実世界の認証機構
https://gyazo.com/58ba83f7368ca767ab28ffb25a368d1f.png
公証役場
公正証書の作成
私文書の認証
確定日付の付与
市役所
PKI
公開鍵暗号を使用したセキュリティ・インフラ
認証局 (Certificate Authority) を利用
https://gyazo.com/0647da8a7628a2081e047edfa16b4473.png
共通鍵の受け渡しの危険を回避
公開鍵(pk), 秘密鍵(sk)を利用
pk⇒sk、sk⇒pkを計算不可能
暗号化アルゴリズムEpk
復号化アルゴリズムDsk
m == Dsk(Epk(x))
pkを公開
sshの場合
ssh-keygenコマンドで公開鍵と秘密鍵を生成
公開鍵 id_dsa.pub または id_rsa.pub
秘密鍵 id_dsa または id_rsa
公開鍵をサーバにコピー
パソコンに秘密鍵を保持
秘密鍵の管理は注意が必要
デモ: ssh
% ssh-keygen
SSL
Secure Sockets Layer
1994ごろNetscapeが開発
ブラウザとサーバの間で秘密通信に利用
https://(url)
公開鍵暗号の特徴
公開鍵を共有していれば安全な暗号化通信が可能
よく知らない相手の場合、公開鍵の正当性を検証する必要がある
認証局
公開鍵の正当性を証明 / 電子証明書発行
認証局が信用できれば、それにより署名された公開鍵を信用できる
認証局の公開鍵は充分信用できると仮定
ブラウザに登録されている
https://gyazo.com/9e9b7d53ce5f24737b725fcbe197a858.png
認証局の階層構造
https://gyazo.com/d3abed0b5c711d0bd2106c9facc4a53e.png
自前の認証局の発行する証明書
ブラウザに登録されていない
認証局に金を払っていない
証明の難しさ
情報の正当性を自力で証明するのは難しい
簡単に作成/コピーできるので
e.g. ある情報が特定の時点で存在したことを証明するのは難しい
公証役場利用
電子公証利用
電子公証の問題点
面倒
金がかかる
気楽に使えない
情報(のハッシュ)をあちこちに登録しておく
情報の存在の証明になるかもしれない
デジタルタイムスタンプ技術
時間に関係する認証
「2年後にならないと情報を公開できないデータを作れるか?」
その他いろいろありそう
オフィシャルな認証局を使わない
本人確認が済んでいる第三者によって署名されている公開鍵は「（ある程度）信用できる」と判断
知り合いに自分の公開鍵に署名してもらうことによって、自分の公開鍵の信用度を保証してもらう
Web上の個人認証サービス
FlickrAPI
TypeKey認証
はてな認証API
livedoor Auth
JugemKey認証API
Facebook のOAuth
特定サービスにパスワードを教えることなくFlickerにアクセスさせる
Flickerのパスワードで別のサービスを利用する
https://gyazo.com/5575fb6404ab2b6f6913944dfbc4456f.png
はてなアカウントによる認証を別サイトで利用
アカウント管理をはてなにアウトソーシング
直接収益なし
知名度向上や新規ユーザ獲得を期待
https://i.gyazo.com/8c320e4e21bc931f824736189f9f0b7c.png
問題点
https://i.gyazo.com/c545180dc113d2aaab03a2d664489bb0.png
各種サービスが乱立
サービスごとに仕様が違う
認証サービスが止まると困る
認証サービスの一本化/標準化
OpenID
OAath
背景技術
シングルサインオン (SSO)
認証と認可
認証 (Authentication)
認可 (Authorization)
認証
ネットワークやサーバへ接続する際に本人性をチェックし、正規の利用者であることを確認する方法。
一般には利用者IDとパスワードの組み合わせにより本人を特定する。
認証がなされると、本人が持つ権限でデータへのアクセスやアプリケーションの利用が可能となる。
不正利用を防ぐため、パスワードの漏えいなどには十分な注意が必要である。
認可
認証（Authentication）によって確認された利用者を識別して、アクセス権限の制御を行い、利用者ごとに固有のサービスを提供すること。
具体的には、利用可能なアプリケーションの制御、ファイルに対する“読み／書き／実行”の権限など、利用者の資格に応じて許可する。認可のための属性情報には、利用者ID／所属グループ／役職／部署／アクセス制御リスト（ACL）などがある。
認証を外部のサービスに任せる仕組み
自分のサービスでパスワード管理しなくてよい
シングルサインオンの標準化
ユーザの指定したURLをIDとして利用
Web用に再設計
ブラウザ利用が前提
認証のみ (認可はやらない)
OpenIDの登場人物
OP（OpenID Provider）
認証サービス提供者 (サービスプロバイダ)
RP（Relying Party）
OpenID認証利用サイト (コンスーマ)
OpenIDアカウント
ユーザ
OpenIDの原理
https://i.gyazo.com/98a5e827a405bd8d1192b65b6fd20700.png
OpenIDの原理
https://i.gyazo.com/25c180ad66415d47e5f6337848aa3e6d.png
OpenIDプロバイダ
https://gyazo.com/9b06c996489f365ae5daffd8a94c77f7.png
その他多数
上記ページのヘッダに以下を記述
code:html
<html>
<head>
<link rel="openid.server"
<link rel="openid.delegate"
voxの認証画面があらわれる
IDとパスワードを入力するとZoooomrに戻る
OpenIDの利用できるサイト
OpenIDの使い勝手
登録とセットアップが面倒
原理がわかりにくい
IDの入力が面倒
普通のID/パスワードのオマケになっている
他サイトに飛ばされるのが不思議/心配
現状
人気は下降気味
仕様がスマートでない気配
心配事
パスワードの外部依託の問題
プロバイダの管理状況が不明
2007ごろ誕生
認可(Authorization)プロトコル
マッシュアップに有用
異なるサービス間のデータ共有をユーザが認可
e.g. TwitterのAPIアクセス権を他アプリに委譲
コンスーマ(e.g. smart.fm)がサービスプロバイダ(e.g. Google)のアクセス権を取得する
かなり複雑...
https://gyazo.com/02a7c417784367f814663dd9021f1056.png
0. ConsumerはService ProviderからあらかじめOAuth利用許可を得る
1. UserがConsumerに，Service Providerから認可が必要な情報へのアクセス権を取得するように指示する。
2. ConsumerはバックグラウンドでService Providerにアクセスし，未認可のRequest Tokenを取得する
3. ConsumerはUserをService Providerにリダイレクトさせる。この際Consumerは未認可のRequest TokenをURL Parameterに付加する
4. UserはService Provider上でConsumerへのアクセス権委譲を許可する。この際Service Providerは未認可のRequest Tokenを認可済とする
5. Service ProviderはUserをConsumerにリダイレクトさせる。この際Service Providerは認可済のRequest TokenをURLに含める
6. ConsumerはバックグラウンドでService Providerと通信を行い，認可済のRequest Tokenを実際のアクセス権を示すAccess Tokenと交換する
7. Consumerは6)で得られたTokenを利用して，特定の情報にアクセスする</span><br>
OAuth認証の例
https://gyazo.com/e5154feec4faf9726a793a39baff7068.png
OpenID vs OAuth
https://gyazo.com/c0d65f550e62d8e3b7867b94a67c5592
認証サービス利用の問題点
原理が難しい!
誰もが理解して使えるのか?
詐偽されやすくならないか?
使い勝手がいまひとつ
うっかりフィッシングにひっかかりやすい
理想の認証を考える
誰でも
どこでも
簡単に
安全に
c.f. 安全と安心
安全 = 客観的
安心 = 主観的
安全とは
受け入れ不可能なリスクがないこと
安全ではないが安心しているもの
車
パスワード
鍵
安全なのに安心していないもの
化学物質
PKI?
安心するものとは
理解できるもの
慣れたもの
親しみのあるもの
歴史を経たもの
パスワードの問題点 (再)
適切なパスワードを選ぶのが困難
覚えるのに苦労する
すぐ忘れる
容易に解読される
安全な運用が難しい
簡単にコピー可能
文字入力装置が必要
認証ハードウェアの問題点 (再)
持ち歩くのが邪魔
持ち歩くのを忘れる
紛失の危険
盗難の危険
生体認証の問題点 (再)
怪我や病気で使えなくなる
コピーされる可能性がある
変更が不可能
パスワード管理システム
複数のパスワードを安全に管理
マスターパスワードが必要
これを忘れると致命的
現在のところこれが最も有効
パスワード管理システム
1Password
LastPass
Just1Key
SuperGenPass
Dashlane
Enpass
SplashID
KeePass
Keeper
...
二段階認証
SMSや電話を利用して確認
電話を紛失すると致命的
「リカバリコード」の管理が大変
理想的な認証
安全な運用
安心感がある
誰でもどこでも簡単に利用
なるべく頭を使わない
認証デバイスを使わない
実現要件
脳内情報だけを利用
知識、能力、etc.
自分だけが実行できる技術を利用
⇒ エピソード記憶を利用
エピソード記憶の特徴
誰もが独自のエピソード記憶を持っている
忘れることがない
他人にはわからない
コピーできない
画像認証
記憶した画像を認証に利用
画像に関連する画像を利用
画像を描く
画像認証解説
情報処理 vol.47, no.5 (2006)
Draw-A-Secret (DAS)
ジェスチャ認証
http://gyazo.com/c8b5733cb850b946e8bfea27dc3fd518.png
DéjàVu
自動生成した画像から認証画像を選択
https://gyazo.com/38a52f9d4f2c67eaf6f6cc7acdf3e13e.png
顔を選択
https://gyazo.com/918210f59d3892b2acdeb7aa276e9863.png
ニーモニックガード
https://www.axseed.co.jp/?page_id=287 https://gyazo.com/7c556f3b48c57da14dcd2868a63b64fa
LockTile
https://gyazo.com/d819ab10b299cc8cb8769b81ff342a8c
特定の点を選択
https://gyazo.com/2dbb4edc510938f3f23a0811e6b12ea6.png
PassPoints
https://gyazo.com/eb52cc445b41c141dae0c2425b962d19.png
画像のカテゴリを選択
OpenIDに対応
https://gyazo.com/a5e94fe05d651e09b942566eba50684b.png
三角形方式
自分の画像を頂点とする三角形の内側の画像を選択
覗き見対策
https://gyazo.com/351a3b2722a7f524c2271812f07308c5.png
GATESCEME
https://gyazo.com/81ebd8dd7d8957b7a8418f515d42f7e9.png
画像と数字を一緒に覚える
Recall-a-Story
https://gyazo.com/80cf70536ce29eb3e8afcde8e93f30f6.png
画像に関連する物語を覚えておく
MARASIM
https://gyazo.com/7cc969827bd1b4d58449afc0b6daeafa.png
自分の知識にマッチする画像を選択
知識は別の画像を利用
https://gyazo.com/75adce63e0ef68b5e2e41aac155cab96.png
潜在記憶を利用するもの
https://gyazo.com/936884a1c4ed1dfec042c2e2d5fb501b.png
画像認証システムの問題点
記憶が持続すると思えないものが多い
異常に手間が多いものが多い
なぞなぞ画像認証
個人的記憶と結び付いた画像から問題を生成
正答を選ぶと認証成功
デモ
なぞなぞ画像認証の利点
忘れない
入力が簡単
認証レベルを設定できる
グループで利用できる
なぞなぞ画像認証の問題点
問題作成が面倒
安心感が欠如
エピソード記憶からパスワードを生成
なぞなぞ問題に答えてシード文字列をパスワード文字列に変換
http://EpisoPass.com https://gyazo.com/795316ca9f1305f4e41c5f095a0197e0.png
なぞなぞ問題
デモ: EpisoDAS
デモ: EpisoPass拡張機能
Chromeの拡張機能
Amazon, Twitterなどで利用可能
デモ: 増井のパスワード
EpisoPassの利点
パスワード生成に必要なあらゆる情報を公開可能
紛失の心配がない
パスワードを忘れることがない
どのようなマシンでも利用できる
既存パスワードも利用できる
シードを設定
問題作成のコツ
答のリストを用意する
昔の知人の名字
県名リスト
それから問題を考える
その方がエピソードを思い出しやすい
認証とヒューマンファクター
安全性の検討は多い
暗号の強度
認証の強度
ヒューマンファクターの議論が不充分
安心感
使いやすさ
運用上の問題
安心感
安心するためには理解が必要
パスワード?
暗号?
公開鍵?
認証局?
OpenID?
安全性が全くわからない
⇒ 安心できない
使いやすさ
インストールが面倒
毎回使うのが面倒
パスワードが覚えられない
⇒ 安全性を犠牲にしがち
運用上の問題
パソコンに重要情報が入りすぎ
ブラウザがパスワードを記憶
秘密鍵
sshのキー
パソコンを盗まれると大変困る
盗まれた後の対策が難しい
c.f. s/key
マシン毎にインストールが必要
毎回チャレンジ/レスポンスが必要
通信が暗号化されるわけではない
sshでは通信がすべて暗号化
現在は廃れてしまった?
将来展望
各種の新しいサービスが出現中
もっと良い認証/暗号化に期待
http://mypico.org/ http://gyazo.com/deca5de3a60363eaa7d6b14a70f5ca5c.png
Cambridge大学のパスワード撲滅システム
共同研究者として参加 (2016春学期)
認証端末を利用することでパスワード問題を解決
ビデオ: Pico
https://vimeo.com/82448991