dackdive's blog

新米webエンジニアによる技術ブログ。JavaScript(React), Salesforce, Python など

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

行ってきました。

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

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

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

以下メモ書き。


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

前フリ

本題

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 より引用)

  • 多表式暗号
    • シーザー改良
    • 平文をブロックに分け、ブロック毎にずらす文字数を変えた
  • エニグマ暗号機
  • まとめ
    • 構造はオープンにすべき
    • 当時、最高の暗号であっても新しい算法・機械の発展により簡単に解読できる時代がそのうちやってくる
    • 技術者は常に新しい暗号を使え


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

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

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


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

  • ブログ: 自堕落な技術者の日記 - livedoor Blog(ブログ)
  • 趣味で証明書集めしてる(!!)
  • 例: amazon での買い物
    • クレジットカード番号、住所・氏名、秘密にしたい買い物
    • SSL/TLSが守るもの:「カード番号、住所・氏名、買い物の内容」を途中で見られたくない
  • SSL/TLS の3つの機能
    • 機密性: のぞき見防止。共通鍵暗号を使う
    • 相手認証: なりすまし防止。PKI, パスワード、Kerberos認証
    • 完全性: 改ざん防止。MAC(メッセージ認証コード) を使う
  • SSL/TLSOSI参照モデルでいうセッション層とプレゼンテーション層に入れるもの?
  • イマドキの証明書を購入する際の注意点
  • Let's Encrypt
    • 簡単、安全、早い、無料、オープン
    • 誰でも証明書をゲットできる
  • 証明書の種類
  DV(ドメイン認証) OV(組織認証) EV(拡張認証)
アドレスバー OVと同じ DVと同じ 緑アドレスバーに組織名が表示される
ページ情報 組織名が表示されない 組織名が表示されない 組織名が表示 される
証明書ビューア 組織名が表示されない 組織名が表示 される 組織名が表示 される
  • SHA1からSHA2証明書への移行
  • なぜ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は?
      • 楕円曲線は楕円ではない (!)
      • y2 = x3 + ax + b で表される関数

f:id:dackdive:20151114181059p:plain
(スライドから引用)

さて、肝心の楕円曲線暗号アルゴリズムについては、、、
正直理解するところまでいかなかった。

ただ、こちらのスライドも参考にすると理解が深まるかも。

たぶん、剰余の考え方を用いることで楕円曲線上の点の加算・乗算を定義して、
ある点 G(x, y) を n 回掛けあわせた移動後の点 nG を公開鍵として用いる、みたいな話だった気がする。

n 回掛け合わせるとは、楕円曲線上の離散的な点の間を n 回移動するようなイメージらしい。

f:id:dackdive:20151114182152p:plain (http://www.slideshare.net/tyk97/ss-35444178 より引用)

このとき、

  • プライベート鍵
    • n: 何回移動するか
  • アルゴリズム
    • 基準点G (x, y)
    • 剰余の素数 p
    • 曲線定数 a
    • 曲線定数 b
  • 公開鍵
    • nG

となる。
nG から n を求めるのはひじょーに難しい。らしい。

また、

  • 曲線パラメータは何でも良いわけではない
    • パラメータの取り方によっては計算が発散する...?
    • 標準化団体、業界団体が良いパラメータを選んだ
    • 代表的なもの: NIST P-256, P-384, P-521, secp256r1, ...

参考書籍・リンク

セッション中にたびたび取り上げられてた結城さんの本、時間のあるときに読んでみたい。

あと、SSL/TLS だと少し前にソフトウェア・デザインで特集組まれてたはず。

リンク(上にも書いたものをまとめ)