Webシステムのためのエンドユーザ
向け公開鍵認証機能の開発
Code4Lib JAPAN Conference 2017@熊本
阪口哲男
筑波大学図書館情報メディア系
saka@slis.tsukuba.ac.jp
2017/9/3
Webシステムのためのエンドユーザ向け公
開鍵認証機能の開発
1
自己紹介 (今日のお題関連で)
• 筑波大学図書館情報メディア系准教授
– 系のシステム管理グループ主査
– 系の情報環境委員会副委員長(技術担当)
• 歴史的経緯?
– 1988年頃より図書館情報大学の電子メールサーバ管理
者(postmaster)を務める(JUNET)
– 1990年代に図書館情報大学においてUnix系OSの教育シ
ステム導入・運用、LANやインターネットとの相互接続とそ
の管理、公式Webサーバ等の立ち上げを行う
– 筑波大学との統合(2002年)後、主に部局内システムや
LANの管理・運用に関わる
• 必然的にセキュリティ問題への対応も
2017/9/3
Webシステムのためのエンドユーザ向け公
開鍵認証機能の開発
2
本日のアウトライン
• デモ: サンプルシステム
• パスワードの漏えいと使い回し問題
• パスワードによらないユーザ認証
– Webで「公開鍵認証」の現状?
– だれでも使えるような公開鍵認証を
• エンドユーザ向けの公開鍵認証
• サンプルシステムの構築と課題等
• 原理的弱点は?
• その他: 標準化動向&応用
2017/9/3
Webシステムのためのエンドユーザ向け公
開鍵認証機能の開発
3
デモ: サンプルシステム
• RubyによるCGIプログラムの例のための例
– Unixのfortuneメッセージが読めるだけ:-)
• 「config.rb」という設定ファイルで変更可能
– パスワード認証と公開鍵認証を切替、比較可能
• 認証関係機能概要
– サインアップではメールアドレス入力、メールで届い
たPINを入力してサインアップ完了
– 公開鍵・秘密鍵ペアのファイルの保存・読込可能
• (demo https://sakura.sakalab.org/~saka/pka4/home.cgi)
2017/9/3
Webシステムのためのエンドユーザ向け公
開鍵認証機能の開発
4
パスワードの漏えいと使い回し問題
• パスワード認証
– ユーザ識別名と(秘密の)パスワードの組が合致すれ
ば、正当なユーザであると認める方式
– ユーザが入力するパスワードが正しいかどうかを検
証できなければならない
• (暗号化した)パスワードをサービス側で保存する
• 漏えい→解読不可でも力技照合でパスワード判明の場合も
• パスワードの使い回し
– あるサービスのパスワードが漏えいすると芋蔓式に
他サービスも不正使用されてしまう
2017/9/3
Webシステムのためのエンドユーザ向け公
開鍵認証機能の開発
5
パスワードによらないユーザ認証
• パスワード使い回し対策は?
– パスワード管理ツール、多要素認証などなど、、、
– そもそもユーザとサービス側で共通のパスワードを
「知っている」という方式を止められないか?
• 「公開鍵認証」があるじゃないか!
– Unix/Linuxユーザにお馴染のSSHでは一般的
– 手元のPCで公開鍵と秘密鍵のペア(鍵ペア)を生成し
て、サーバに公開鍵を登録
– そのペアとなる秘密鍵を持っているPCからはパス
ワードを使わずログインできる
2017/9/3
Webシステムのためのエンドユーザ向け公
開鍵認証機能の開発
6
Webで「公開鍵認証」の現状?
• 実はSSL/TLS規格に「個人証明書」認証あり
– でも、だれがどこで使ってますか?:-)
• 事前に個人証明書の発行を認証局などで受ける
• それをOSあるいはブラウザの証明書管理機能でインストー
ルが必要
• 他の実装: TrustAuth http://trustauth.com/
– 簡単に使えそう?
– でも、Firefox専用(プラグインが必要)
– ブラウザの移行が困難(鍵のexport/importなし)
• Web標準動向については後で、、、、
2017/9/3
Webシステムのためのエンドユーザ向け公
開鍵認証機能の開発
7
だれでも使えるような公開鍵認証を
• ブラウザに依存せずできないか?→Web標準
– 問題は鍵の保存・管理
– そういえば、HTML5に「localStorage」がある!
• というわけで、卒研で試作してもらった
– 2014年度、関春奈さん
– 抄録: http://klis.tsukuba.ac.jp/archives/2014/s1111519-
2015020619232710336A.pdf †
• † 筑波大学情報学群知識情報・図書館学類で公開
– 一通り機能を実現可能なことを確認済
• (その後、「諸般の事情」により2年ちょっと停滞)
2017/9/3
Webシステムのためのエンドユーザ向け公
開鍵認証機能の開発
8
• 公開鍵暗号技術について (注: 大幅に端折ってます)
• x: 平文、y: 暗号文
• 暗号化: y = f(x, k1)、復号化: x = g(y, k2)
• k1: 暗号化鍵、k2: 復号化鍵
• 例: k1≠k2、かつk1からk2への推定困難ならk1を公開可能
エンドユーザ向けの公開鍵認証(1/4)
2017/9/3
Webシステムのためのエンドユーザ向け公
開鍵認証機能の開発
9
x
y
xf() g()
Aさん Bさん
k1 k2
エンドユーザ向けの公開鍵認証(2/4)
• ポイント1: 鍵k1が漏れてもk2は守られる
– (パスワード)漏えいを気にしなくて良い?
• ポイント2: 鍵k1とk2の組合せは決まっている
– 相手がどの鍵の所有者かを識別できる
• 試作システムでとった方式
– 鍵ペアを生成して、公開鍵をサーバに預ける
– 認証は、サーバから送った符丁をブラウザが秘
密鍵で暗号化してサーバに返す。サーバはそれ
を公開鍵で復号化に成功すれば認証完了
2017/9/3
Webシステムのためのエンドユーザ向け公
開鍵認証機能の開発
10
エンドユーザ向けの公開鍵認証(3/4)
• 今回の発表に向けてコード整理と再実装
– サンプル・システムとしてgithub公開を目指す
– 要件の最少化:
• サーバ: Apache httpd, Ruby, SQLite3 (他のRDBMSも可)
• ブラウザ: HTML5(含JavaScript)対応
– 使用プログラムライブラリ
• Ruby2.x: 標準添付ライブラリ+ gem sqlite3
• JavaScript: jsrsasign (http://kjur.github.io/jsrsasign/)
– その他 – HTTPS (SSL/TLS)対応は今時必須でしょう
2017/9/3
Webシステムのためのエンドユーザ向け公
開鍵認証機能の開発
11
エンドユーザ向けの公開鍵認証(4/4)
• 認証手順の見直し: デジタル署名を採用
• 手順
– まず秘密鍵と公開鍵のペアを生成し、サーバに
公開鍵を預ける (サインアップ)
– サインインの際、ブラウザが秘密鍵を用いてサー
バから届いた符丁のデジタル署名を生成し、
サーバに返す
– サーバは預かっている公開鍵を用い、その署名
が送った符丁に対するものか検証→成功ならOK
2017/9/3
Webシステムのためのエンドユーザ向け公
開鍵認証機能の開発
12
サンプルシステムを構築して
• 実際書いてみると、パスワード認証とコード量自
体は大差ない (jsrsasignのおかげでもある)
– この辺は公開するコードを見てください
• エンドユーザの操作も大差ない?
– サインアップ、サインインともに
– ブラウザ移行等の際の鍵管理は必要
• パスワードリセット過程と同様にもできる
• なおブラウザの互換性対応は頑張ってません
– 建前: Web標準HTML5に基づいているはず、、
2017/9/3
Webシステムのためのエンドユーザ向け公
開鍵認証機能の開発
13
• 複数端末対応
– 他の端末で使う際は秘密鍵の保存と読込が必要
– 秘密鍵のコピーはちょっと問題、、、、
• 公開鍵の変更・預け直し過程の更なる検証
• コードのリファイン
– (2週間ほどで「エイヤっと」書いたのでさすがに…)
• (他にもブラウザの互換性など多々ありそう、、、)
• コード公開予定地: https://github.com/tsaka1/pka-
sample-c4ljp2017
サンプルシステムの課題
2017/9/3
Webシステムのためのエンドユーザ向け公
開鍵認証機能の開発
14
原理的な弱点は?
• 秘密鍵を保存しているlocalStorageの保護
– Same origin原則でアクセス制限されているが、ド
メイン名詐称されると読み取られてしまう。
• DNS毒入れ攻撃の危険
• そのためにもHTTPS (SSL/TLS) でサーバ証明書必須
• 同じドメイン名で異なる主体が同居するのも危険
– SSHなどと同様に秘密鍵をパスフレーズで暗号化
して保存(これは実装済)
• 時間をかければ秘密鍵推定可能→鍵を長く
2017/9/3
Webシステムのためのエンドユーザ向け公
開鍵認証機能の開発
15
その他: 標準動向&応用
• 実は暗号についてのAPI標準がW3C勧告に
– Web Cryptography API (W3C Recommendation 26
January 2017)
– https://www.w3.org/TR/WebCryptoAPI/
– でもブラウザの対応状況は???
• 秘密鍵の管理が面倒そう?
– パスワード認証と併用する多要素認証の1要素
に使うという手もある
• ご意見あればお気軽に&fork歓迎!
2017/9/3
Webシステムのためのエンドユーザ向け公
開鍵認証機能の開発
16
Acknowledgements
• 指導教員の無茶ぶりに応えてくれた関春奈さん
• 自堕落な技術者の日記 - livedoor Blog(ブログ)
– http://blog.livedoor.jp/k_urushima/
– jsrsasignの作者ブログ
– 暗号技術や証明書の扱い事例色々
• PKI.js - https://pkijs.org/
– Web Cryptography APIベースのPKIライブラリ
– W3Cの標準動向に気付かせてくれた
– 再実装で使用を検討したが結局使わず
• 結城浩著. 暗号技術入門.
https://calil.jp/book/4797382228
2017/9/3
Webシステムのためのエンドユーザ向け公
開鍵認証機能の開発
17

Webシステムのためのエンドユーザ向け公開鍵認証機能の開発

  • 1.
    Webシステムのためのエンドユーザ 向け公開鍵認証機能の開発 Code4Lib JAPAN Conference2017@熊本 阪口哲男 筑波大学図書館情報メディア系 saka@slis.tsukuba.ac.jp 2017/9/3 Webシステムのためのエンドユーザ向け公 開鍵認証機能の開発 1
  • 2.
    自己紹介 (今日のお題関連で) • 筑波大学図書館情報メディア系准教授 –系のシステム管理グループ主査 – 系の情報環境委員会副委員長(技術担当) • 歴史的経緯? – 1988年頃より図書館情報大学の電子メールサーバ管理 者(postmaster)を務める(JUNET) – 1990年代に図書館情報大学においてUnix系OSの教育シ ステム導入・運用、LANやインターネットとの相互接続とそ の管理、公式Webサーバ等の立ち上げを行う – 筑波大学との統合(2002年)後、主に部局内システムや LANの管理・運用に関わる • 必然的にセキュリティ問題への対応も 2017/9/3 Webシステムのためのエンドユーザ向け公 開鍵認証機能の開発 2
  • 3.
    本日のアウトライン • デモ: サンプルシステム •パスワードの漏えいと使い回し問題 • パスワードによらないユーザ認証 – Webで「公開鍵認証」の現状? – だれでも使えるような公開鍵認証を • エンドユーザ向けの公開鍵認証 • サンプルシステムの構築と課題等 • 原理的弱点は? • その他: 標準化動向&応用 2017/9/3 Webシステムのためのエンドユーザ向け公 開鍵認証機能の開発 3
  • 4.
    デモ: サンプルシステム • RubyによるCGIプログラムの例のための例 –Unixのfortuneメッセージが読めるだけ:-) • 「config.rb」という設定ファイルで変更可能 – パスワード認証と公開鍵認証を切替、比較可能 • 認証関係機能概要 – サインアップではメールアドレス入力、メールで届い たPINを入力してサインアップ完了 – 公開鍵・秘密鍵ペアのファイルの保存・読込可能 • (demo https://sakura.sakalab.org/~saka/pka4/home.cgi) 2017/9/3 Webシステムのためのエンドユーザ向け公 開鍵認証機能の開発 4
  • 5.
    パスワードの漏えいと使い回し問題 • パスワード認証 – ユーザ識別名と(秘密の)パスワードの組が合致すれ ば、正当なユーザであると認める方式 –ユーザが入力するパスワードが正しいかどうかを検 証できなければならない • (暗号化した)パスワードをサービス側で保存する • 漏えい→解読不可でも力技照合でパスワード判明の場合も • パスワードの使い回し – あるサービスのパスワードが漏えいすると芋蔓式に 他サービスも不正使用されてしまう 2017/9/3 Webシステムのためのエンドユーザ向け公 開鍵認証機能の開発 5
  • 6.
    パスワードによらないユーザ認証 • パスワード使い回し対策は? – パスワード管理ツール、多要素認証などなど、、、 –そもそもユーザとサービス側で共通のパスワードを 「知っている」という方式を止められないか? • 「公開鍵認証」があるじゃないか! – Unix/Linuxユーザにお馴染のSSHでは一般的 – 手元のPCで公開鍵と秘密鍵のペア(鍵ペア)を生成し て、サーバに公開鍵を登録 – そのペアとなる秘密鍵を持っているPCからはパス ワードを使わずログインできる 2017/9/3 Webシステムのためのエンドユーザ向け公 開鍵認証機能の開発 6
  • 7.
    Webで「公開鍵認証」の現状? • 実はSSL/TLS規格に「個人証明書」認証あり – でも、だれがどこで使ってますか?:-) •事前に個人証明書の発行を認証局などで受ける • それをOSあるいはブラウザの証明書管理機能でインストー ルが必要 • 他の実装: TrustAuth http://trustauth.com/ – 簡単に使えそう? – でも、Firefox専用(プラグインが必要) – ブラウザの移行が困難(鍵のexport/importなし) • Web標準動向については後で、、、、 2017/9/3 Webシステムのためのエンドユーザ向け公 開鍵認証機能の開発 7
  • 8.
    だれでも使えるような公開鍵認証を • ブラウザに依存せずできないか?→Web標準 – 問題は鍵の保存・管理 –そういえば、HTML5に「localStorage」がある! • というわけで、卒研で試作してもらった – 2014年度、関春奈さん – 抄録: http://klis.tsukuba.ac.jp/archives/2014/s1111519- 2015020619232710336A.pdf † • † 筑波大学情報学群知識情報・図書館学類で公開 – 一通り機能を実現可能なことを確認済 • (その後、「諸般の事情」により2年ちょっと停滞) 2017/9/3 Webシステムのためのエンドユーザ向け公 開鍵認証機能の開発 8
  • 9.
    • 公開鍵暗号技術について (注:大幅に端折ってます) • x: 平文、y: 暗号文 • 暗号化: y = f(x, k1)、復号化: x = g(y, k2) • k1: 暗号化鍵、k2: 復号化鍵 • 例: k1≠k2、かつk1からk2への推定困難ならk1を公開可能 エンドユーザ向けの公開鍵認証(1/4) 2017/9/3 Webシステムのためのエンドユーザ向け公 開鍵認証機能の開発 9 x y xf() g() Aさん Bさん k1 k2
  • 10.
    エンドユーザ向けの公開鍵認証(2/4) • ポイント1: 鍵k1が漏れてもk2は守られる –(パスワード)漏えいを気にしなくて良い? • ポイント2: 鍵k1とk2の組合せは決まっている – 相手がどの鍵の所有者かを識別できる • 試作システムでとった方式 – 鍵ペアを生成して、公開鍵をサーバに預ける – 認証は、サーバから送った符丁をブラウザが秘 密鍵で暗号化してサーバに返す。サーバはそれ を公開鍵で復号化に成功すれば認証完了 2017/9/3 Webシステムのためのエンドユーザ向け公 開鍵認証機能の開発 10
  • 11.
    エンドユーザ向けの公開鍵認証(3/4) • 今回の発表に向けてコード整理と再実装 – サンプル・システムとしてgithub公開を目指す –要件の最少化: • サーバ: Apache httpd, Ruby, SQLite3 (他のRDBMSも可) • ブラウザ: HTML5(含JavaScript)対応 – 使用プログラムライブラリ • Ruby2.x: 標準添付ライブラリ+ gem sqlite3 • JavaScript: jsrsasign (http://kjur.github.io/jsrsasign/) – その他 – HTTPS (SSL/TLS)対応は今時必須でしょう 2017/9/3 Webシステムのためのエンドユーザ向け公 開鍵認証機能の開発 11
  • 12.
    エンドユーザ向けの公開鍵認証(4/4) • 認証手順の見直し: デジタル署名を採用 •手順 – まず秘密鍵と公開鍵のペアを生成し、サーバに 公開鍵を預ける (サインアップ) – サインインの際、ブラウザが秘密鍵を用いてサー バから届いた符丁のデジタル署名を生成し、 サーバに返す – サーバは預かっている公開鍵を用い、その署名 が送った符丁に対するものか検証→成功ならOK 2017/9/3 Webシステムのためのエンドユーザ向け公 開鍵認証機能の開発 12
  • 13.
    サンプルシステムを構築して • 実際書いてみると、パスワード認証とコード量自 体は大差ない (jsrsasignのおかげでもある) –この辺は公開するコードを見てください • エンドユーザの操作も大差ない? – サインアップ、サインインともに – ブラウザ移行等の際の鍵管理は必要 • パスワードリセット過程と同様にもできる • なおブラウザの互換性対応は頑張ってません – 建前: Web標準HTML5に基づいているはず、、 2017/9/3 Webシステムのためのエンドユーザ向け公 開鍵認証機能の開発 13
  • 14.
    • 複数端末対応 – 他の端末で使う際は秘密鍵の保存と読込が必要 –秘密鍵のコピーはちょっと問題、、、、 • 公開鍵の変更・預け直し過程の更なる検証 • コードのリファイン – (2週間ほどで「エイヤっと」書いたのでさすがに…) • (他にもブラウザの互換性など多々ありそう、、、) • コード公開予定地: https://github.com/tsaka1/pka- sample-c4ljp2017 サンプルシステムの課題 2017/9/3 Webシステムのためのエンドユーザ向け公 開鍵認証機能の開発 14
  • 15.
    原理的な弱点は? • 秘密鍵を保存しているlocalStorageの保護 – Sameorigin原則でアクセス制限されているが、ド メイン名詐称されると読み取られてしまう。 • DNS毒入れ攻撃の危険 • そのためにもHTTPS (SSL/TLS) でサーバ証明書必須 • 同じドメイン名で異なる主体が同居するのも危険 – SSHなどと同様に秘密鍵をパスフレーズで暗号化 して保存(これは実装済) • 時間をかければ秘密鍵推定可能→鍵を長く 2017/9/3 Webシステムのためのエンドユーザ向け公 開鍵認証機能の開発 15
  • 16.
    その他: 標準動向&応用 • 実は暗号についてのAPI標準がW3C勧告に –Web Cryptography API (W3C Recommendation 26 January 2017) – https://www.w3.org/TR/WebCryptoAPI/ – でもブラウザの対応状況は??? • 秘密鍵の管理が面倒そう? – パスワード認証と併用する多要素認証の1要素 に使うという手もある • ご意見あればお気軽に&fork歓迎! 2017/9/3 Webシステムのためのエンドユーザ向け公 開鍵認証機能の開発 16
  • 17.
    Acknowledgements • 指導教員の無茶ぶりに応えてくれた関春奈さん • 自堕落な技術者の日記- livedoor Blog(ブログ) – http://blog.livedoor.jp/k_urushima/ – jsrsasignの作者ブログ – 暗号技術や証明書の扱い事例色々 • PKI.js - https://pkijs.org/ – Web Cryptography APIベースのPKIライブラリ – W3Cの標準動向に気付かせてくれた – 再実装で使用を検討したが結局使わず • 結城浩著. 暗号技術入門. https://calil.jp/book/4797382228 2017/9/3 Webシステムのためのエンドユーザ向け公 開鍵認証機能の開発 17