技術/Security/PKI,SSL,TLS/SSL, Certificate, Public Key Pinning (v1)

• [ Prev ]
• [ Next ]
• [ 技術 ]

勉強中のメモ。

• Certificate and Public Key Pinning - OWASP
  • https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning
• Certificate and Public Key Pinning | グローバルサインブログ｜SSLサーバ証明書ならグローバルサイン (旧日本ジオトラスト株式会社)
  • https://jp.globalsign.com/blog/2013/certificate_public_key_pinning.html
• SSL Pinning for Increased App Security by Jay Graves of Double Encore
  • http://www.doubleencore.com/2013/03/ssl-pinning-for-increased-app-security/
• LumberBlog: Why app developers should care about SSL pinning
  • http://blog.lumberlabs.com/2012/04/why-app-developers-should-care-about.html
• スマートフォンアプリのSSLとかの解説っぽいもの - Togetter
  • http://togetter.com/li/253658

• 目的
  • OSやライブラリによる証明書チェーンの検証に頼らず、アプリケーション側で独自に、接続先のサーバ証明書を検証する。

• 技法
  • SSL/TLS通信を行うアプリケーションで、サーバ証明書の検証時に、証明書の公開鍵や署名、ホスト名などをアプリ側で持っているリストと一致しているか検証する。

• 誰が行うのか
  • アプリケーションの開発者が行う。ChromeなどWebブラウザアプリや、スマホアプリなど、SSL/TLS接続を行うアプリケーション全般の開発者が行う。

• 背景 (より突っ込んだ"目的")
  • 1. 認証局自体が攻撃されて、不正に証明書を発行される事例が近年発生している。不正に発行された証明書を使った悪意のあるサーバに対して、中間者攻撃などを使って誘導された場合、単にルート認証局からの証明書チェーンを検証しただけでは、本当に接続先のサーバが正規のサーバであるか検証できたことにならない。このため、サーバ証明書自体をアプリ側でも検証し、アプリ側に埋め込まれている正規のサーバ証明書と同じ内容か検証する。もしアプリ側の証明書情報と一致しなければ、攻撃者により誘導された不正なサーバに接続している可能性があることを判別できる。
    • 例 : ルート認証局のシステムが攻撃され、攻撃者により勝手にGoogle.comの証明書が発行され、攻撃者が用意したサーバに設定されるケース。攻撃によるものとはいえ、証明書自体は正規のルート認証局から発行されたものであるため、検証自体は成功する。その結果、被害者はGoogle.comに接続していると思い込んで、実際は攻撃者により誘導されたサーバに接続し、重要情報をやりとりする。
  • 2. 悪意のあるアプリケーションの利用者により、SSL/TLS通信を傍受・改ざんされることを防ぐ。
    • BurpなどMITMに対応してSSL/TLSの内容を傍受・改ざん可能なプロキシツールがある。
    • これらのプロキシツールはアプリから接続された時にプロキシツール自身がSSL/TLSハンドシェイクを行う。この時、プロキシツールはアプリに対して、アプリ自身が生成したサーバ証明書を提示し、サーバとして振る舞う。プロキシツールは内部で生成した独自のルートCA証明書を保持し、共通してそれを認証局としてサーバ証明書を生成する仕組みを有する（場合が多い）。
    • アプリケーションの通信を解析したい利用者は、これらプロキシツールのルートCA証明書をエキスポートした後、自身の環境に信頼できるルート認証局の証明書としてインポートする。
      • この部分の難易度をPC/iOS/Androidそれぞれで正確に判定できる情報は持ち合わせてないので不明。
    • このため、単に証明書のキーチェーンだけを検証するだけでは、プロキシツールが介在していることを検出出来ない。サーバ証明書までをアプリ独自に検証することにより、もし一致していなければ、プロキシツールが生成した証明書でありプロキシツールが介在している可能性が考えられ、通信エラーとするなどしてSSL/TLS通信内容を傍受・改ざんされることを防ぐことが可能になる。（100%防ぐことは出来なくとも、難易度を上げることはできる）
  • 3. 金銭面などもろもろの事情により、一般の認証局で証明書を発行できず、自己署名証明書を使いたい。証明書の検証を全く行わない事は危険なので、自己署名証明書のサーバ証明書をアプリ側で保持しておき、OS/ライブラリのルート認証局からのチェーン検証は行わず、サーバ証明書の情報だけを検証したい。
  • (他に何かあるか？)

• • 実装にはいくつかのバリエーションがありそう。
    • Chrome : Google.comの証明書について、予めChrome内にホワイトリストが埋め込まれていて、それらとの一致を検査しているらしい。
    • 単一のサーバとしか通信しないアプリケーションなら、開発者が予めそのサーバの証明書を入手して、それらの情報をアプリに埋め込み、それと一致するかチェックできそう。
    • Webブラウザなど不特定多数のサーバと接続する場合：そのサーバに最初に接続した時のサーバ証明書情報を覚えておいて、2回め以降の接続でそれと異なるようであれば警告あるいはエラーとするなどありそう。SSHクライアントでよく見かける。
      • ただしこの場合、初回接続時に既に攻撃を受けて攻撃者のサーバに誘導されていればナンセンスである。
    • そもそも、OS/ライブラリのルート認証局の証明書ストアを使ったチェーン検証＋独自のサーバ証明書検証を行うのか、チェーン検証は行わずに、単にサーバ証明書の検証だけにするのか、でも違いが出そう。

• デメリット
  • サーバ証明書が再発行などで変更された場合、アプリ側に埋め込んだ情報も同期させる必要がある。つまり、アプリも同時に変更して配布する必要があり、自動更新処理などを検討する必要が生じる。

• メモ
  • Pinningしていないのはアプリケーションの脆弱性か？・・・どうなんだろう・・。
  • 背景の2番目、SSL/TLS通信の傍受・改ざんを防ぐためというのは個人的にはあんまりオススメしたく無いかな・・・。アプリの利用者自身により通信内容が見られて、改ざんされても、それでもセキュリティが担保されるようにシステムを作っておくほうが順序としては先の気がする。ただそういう要望がある、かもしれない、というのは認識しておきたところ。

他：

• Forward Secrecy at Twitter | Twitter Blogs
  • https://blog.twitter.com/2013/forward-secrecy-at-twitter-0
    • SSL/TLSの接続開始時のセキュリティ技術である "Forward Secrecy" をTwitterでも取り入れてみたよ、という記事(多分)。・・・なんだけど、最後のほうでHTTPSをより強化するためになぜかcertificate pinningが推奨されてる。HSTSとかと一緒になってるので、HTTPS関連の最近の改良トピックを一緒くたに推奨として混ぜ込んだだけ？
• SSL/TLS & Perfect Forward Secrecy | Vincent Bernat
  • http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html
    • "Forward Secrecy" の解説記事。SSL/TLSの鍵交換に使うアルゴリズムとかその辺の話っぽい。

• [ Prev ]
• [ Next ]
• [ 技術 ]