#qpstudy 2015.11 セキュリティに万全を求めるのは間違っているだろうか　〜絶対なんてない〜に行ってきた

行ってきました。

http://www.zusaar.com/event/14207003

Web アプリケーションエンジニアなので分からない点も多々ありましたが、
登壇者のお話がわかりやすく非常に勉強になりました。

初参加だったんですが、全体的にゆる〜い雰囲気で良いですね。

以下メモ書き。

暗号化の歴史 (しょっさん @sho7650)

前フリ

BABYMETAL と Perfume は覚えて帰ってください
シェルスクリプトマガジンでrubyの連載中

本題

暗号が必要な理由
- 軍事・外交
参考書
- 暗号技術入門第3版
- 暗号　情報セキュリティの技術と歴史 (講談社学術文庫)
言葉の定義
- 平文(ひらぶん): 原文となる、文章、キーワード
- 暗号文: 平文を、アルゴリズムと鍵によって変換された結果
- アルゴリズム: 鍵にしたがって、変換するための手順
- 鍵: アルゴリズムに必要な、重要な要素
スキュタレー暗号：物理的な鍵の先駆者
- 鍵は木の棒
- 紙を木の棒に巻く
- 同じ直径だと同じ言葉が出てくる

f:id:dackdive:20151114143139g:plain (http://www.mitsubishielectric.co.jp/security/learn/info/misty/stage1.html より引用)

シーザー暗号
- 文字を一定数ずらす
- ずらす数 = 鍵
- 欠点: 単純。アルファベットなら26回の試行でいける

f:id:dackdive:20151114165543p:plain
(https://ja.wikipedia.org/wiki/%E3%82%B7%E3%83%BC%E3%82%B6%E3%83%BC%E6%9A%97%E5%8F%B7 より引用)

単文字(単一)換字暗号
- 変換前と変換後のアルファベット対応をランダムに
- アルファベットだけでも 26! 通りの組み合わせ
- それでもばれた
  - なぜか？ → 文字の頻度分析 (母音の方が登場回数が多い)

f:id:dackdive:20151114165610p:plain (http://labs.opentone.co.jp/?p=3599 より引用)

多表式暗号
- シーザー改良
- 平文をブロックに分け、ブロック毎にずらす文字数を変えた
エニグマ暗号機
- 鍵を日替わりで変える
- ローター3つとリフレクター(合わせてスクランバー) がアルゴリズム
- プラグが鍵
まとめ
- 構造はオープンにすべき
  - 構造(アルゴリズム) がバレたらダメなものは、もはや欠陥商品
- 当時、最高の暗号であっても新しい算法・機械の発展により簡単に解読できる時代がそのうちやってくる
- 技術者は常に新しい暗号を使え

20分でわかった気になる PKI のお話し (ねこるり @nekoruri)

#qpstudy 2015.11 20分でわかるPKI from Masahiro NAKAYAMA

公開鍵暗号
- 2つの鍵を分離
  - 暗号化用の鍵 -> 公開鍵を公開
  - 復号用の鍵 -> プライベート鍵
鍵配送問題
- 鍵を安全に配送する方法が問題
- 共通鍵暗号だと鍵を何らかの別の手段で秘匿しないといけない
デジタル署名
- 公開鍵暗号を「逆向き」に利用
- プライベート鍵で暗号化、みんなに配った公開鍵で復号
鍵配送問題その2
- 公開鍵を配送するときに、第三者が自分の公開鍵と差し替えてしまったら
- いわゆる Man-in-the-middle 攻撃(MITM・中間者攻撃）
- 公開鍵の「真正性」がだいじ
何も信頼できない状態から信頼を作り出す技術はまだ生み出されていません
- 結城浩さんの書籍暗号技術入門第3版より引用
PKI: Public Key Infrastructure 公開鍵基盤
- 公開鍵暗号をうまく使うための枠組み
- PGPとSSHを除く世の中のほぼすべてがこの上に乗っかっている
- 覚えて帰るべきポイント
  - 公開鍵証明書
  - 階層化された認証局(CA)
  - トラストアンカー
公開鍵証明書
- 公開鍵の持ち主を証明するもの
- 公開鍵に第三者がデジタル署名
- 公開鍵の持ち主（＝その公開鍵に対応した秘密鍵の持ち主）を証明するものとして「電子証明書」というものが存在し、その証明書を発行する機関を「認証局」と呼ぶ
- 認証局は送り手Aさんと受け手Bさんが共通して信頼できることが重要
階層化された認証局 (CA)
- Aさんの公開鍵を認証局が認証
- 証明書には認証局の署名が含まれている
- では、認証局の署名が本物かどうか検証するには？ → 認証局の公開鍵が必要
- 認証局の公開鍵にも対応する証明書があり、それはまた別の認証局が署名している
- ...というように、認証局の上の認証局のそのまた上の...と続く → 階層化
- 一番上の認証局を「ルート認証局」と呼ぶ
- 実際のCA階層化は証明書見ればわかる
トラストアンカー
- 「信頼の起点」
  - いわゆる「信頼されたルート証明書」
- ここが侵されたら何をされてもおかしくない

※ PKI についてはこちらの記事も参考にしました。

PKIの基礎を理解しよう！：PKI基礎講座（1） - ＠IT
- 認証局の信用モデルについて https://www.ipa.go.jp/security/pki/051.html

一歩先を行くインフラエンジニアに知ってほしいSSL/TLS設定 (漆嶌さん @kjur)

qpstudy 2015.11.14 一歩先を行くインフラエンジニアに知ってほしいSSL/TLS from Kenji Urushima

ブログ: 自堕落な技術者の日記 - livedoor Blog（ブログ）
趣味で証明書集めしてる(!!)
例: amazon での買い物
- クレジットカード番号、住所・氏名、秘密にしたい買い物
- SSL/TLSが守るもの：「カード番号、住所・氏名、買い物の内容」を途中で見られたくない
SSL/TLS の3つの機能
- 機密性: のぞき見防止。共通鍵暗号を使う
- 相手認証: なりすまし防止。PKI, パスワード、Kerberos認証
- 完全性: 改ざん防止。MAC(メッセージ認証コード) を使う
SSL/TLS はOSI参照モデルでいうセッション層とプレゼンテーション層に入れるもの？
イマドキの証明書を購入する際の注意点
Let's Encrypt
- 簡単、安全、早い、無料、オープン
- 誰でも証明書をゲットできる
証明書の種類

	DV(ドメイン認証)	OV(組織認証)	EV(拡張認証)
アドレスバー	OVと同じ	DVと同じ	緑アドレスバーに組織名が表示される
ページ情報	組織名が表示されない	組織名が表示されない	組織名が表示される
証明書ビューア	組織名が表示されない	組織名が表示される	組織名が表示される

SHA1からSHA2証明書への移行
- MSはSHA1の停止を2017/01 → 2016/06 に早めた
- 参考: https://www.trustworthyinternet.org/ssl-pulse/
なぜHTTPS(SSL/TLS) のサーバー側の設定が大切か
- 近年のSSL/TLSの問題を整理すると、ソフトウェアをアップデートすれば良いだけではすまなくなってきた
暗号スイート (CipherSuite) の設定
- 暗号スイートとは: ウェブブラウザとウェブサーバーが合意する暗号アルゴリズムのセット
  - 最初にクライアントがサーバーに問い合わせる (ClientHello)
    - 「この暗号方式をサポートしてますけど、どうしましょうか？」
  - サーバーはその中から使ってほしい暗号を返す (ServerHello)
    - 「では、これでお願いします」
- サーバー側が返した暗号アルゴリズムで以後通信が行われるため、注意が必要
使って良い(おすすめの)暗号
- 鍵交換: ECDHE, ECDH, RSA, DHE, DH
  - ECDH は楕円曲線暗号?
  - 末尾のEはEphemeral(一時的な) → 長期の暗号解析にも強い??
- 認証: RSA, EXDSA
- 暗号化: AES_XXX_GCM, AES_XXX_CBC (XXX は128, 256)
  - パフォーマンスも考えると128bitの方が良いらしい
残りの3つの大切なSSL/TLS設定
1. POODLE対策として使用プロトコルバージョン
2. CRIME対策としての圧縮設定の解除
参考: SSL/TLS 暗号設定ガイドライン

( ﾟдﾟ)ﾎﾟｶｰﾝ

楕円曲線暗号について

EC (Elliptic Curve)
ECDH(E) 鍵交換、ECDSA署名/証明書
楕円曲線暗号のメリットはコンパクトであること
- 鍵のデータサイズはRSAの1/10以下
- 処理に必要なメモリが小さい→組み込み、ICカードに適している
公開鍵暗号の性質
- ある計算は簡単だけど、逆演算は難しいという性質
- RSA暗号は「大きな2つの数(素数)の掛け算は簡単だけど、結果を逆に因数分解するのは難しい」
- ECは？
  - 楕円曲線は楕円ではない (!)
  - y² = x³ + ax + b で表される関数