Open8

SSL/TLS

しみゆーしみゆー

SSL/TLS

  • Secure Sockets Layer
  • Transport Layer Security
  • TLSの方がSSLよりも新しい(次世代規格)
  • SSLは脆弱性があるため、使用されない。SSLと呼んでいても実態はTLSであることが多い
  • SSLという名称が一般化しているため、いまだにSSLと呼ばれることも多い

トランスポート層で動く

  • トランスポート層のプロトコル
    • TCPとアプリケーションの間に位置する
  • HTTPS以外でも、SMTPやFTPを暗号化することができる
    • SMTP over SSL

役割

盗聴・改ざん・なりすましを防ぐための技術。

  • 暗号化
  • 改ざんの検知
  • 認証

常時SSL化

  • 個人情報を入力するようなシビアなページ以外のWebサイト全体をSSL/TLS化すること
  • SEOにも影響する

しみゆーしみゆー

SSLハンドシェイク

  • 【Client】SSL/TLSバージョンや暗号スイートをサーバに提示
    • 使用できるアルゴリズムをサーバ側に教えておく
  • 【Server】サーバ証明書を送る
  • 【Client】通信相手が本物のサーバかをサーバ側から提示される証明書で確認する
  • 共通鍵の素材(プリマスターシークレット)を交換する
    • 【Client】共通鍵で暗号化して送る
    • 【Server】秘密鍵で復号し、プリマスターシークレットを取り出し、共通鍵を生成
  • ハンドシェイクの終了を互いに確認する

SSLハンドシェイク以降

ハンドシェイク時に生成した共通鍵で暗号&復号を行い、安全にデータ通信する

しみゆーしみゆー

共通鍵暗号方式

  • 暗号鍵と復号鍵に同じ鍵を使用する
  • 第三者に知られてはいけない

メリット

  • 仕組みが単純。暗号化、復号化ともに高速

デメリット

  • 鍵管理が大変
  • 鍵をどう渡すかが問題になる
    • 鍵を秘密裏に渡せるのであれば、そもそも暗号化しなくても良いのでは?となってしまう
  • 通信相手が増えると、鍵を用意するのが大変
しみゆーしみゆー

SSL/TLSで使われるハイブリッド方式

  • 受信側:公開鍵と秘密鍵を生成する
    • 公開鍵は配布し、秘密鍵は受信側だけが保持する
  • 送信側:共通鍵を公開鍵で暗号化して送信する
    • 厳密には、共通鍵を暗号化するのではなく、共通鍵のもとになるもの(プリマスターシークレット)を送信する
  • 受信側:保持している秘密鍵で復号し、共通鍵を取り出す

ここまでで、メッセージの暗号・復号用の共通鍵を両者が持っている状態となった。
以後は、

  • 送信側:共通鍵でメッセージを暗号化して安全に送信する
  • 受信側:共通鍵でメッセージを復号
    という流れで安全にやり取りを行う。
しみゆーしみゆー

ディジタル署名

  • 通信を暗号化し、その送信の真正性と完全性を確認するのに必要。
  • 送りたいメッセージをハッシュ関数でハッシュ化し、それを秘密鍵で暗号化したもの

流れ

  • 送信側:送りたいデータ(①)のハッシュ値を作成
  • 送信側:②自分(送信側)の秘密鍵で署名(ハッシュ値を秘密鍵で暗号化する:ディジタル署名)
  • 送信側:①と②をまとめたものを相手(受信側)の公開鍵を使って暗号化(③)。③を送信する
  • 受信側:③を自分(受信側)の秘密鍵で復号。①と②をゲット
  • 受信側:②を相手(送信側)の公開鍵で復号:本人確認ができた(真正性)
  • 受信側:①のハッシュ値を自分で作成。送信側から送られてきたハッシュ値(②を復号して得られている)を比較する。一致したら、改ざんされていないこと(完全性)が確認できる

ディジタル証明書の必要性

偽物がディジタル署名を付けて送ってきたかもしれない。
その署名が本物であることをどうやって担保するか?

印鑑が正当なものであることを印鑑証明書が証明するように、
ディジタル署名はディジタル証明書が証明する。

ディジタル証明書

  • 本人が署名したことを認証局が証明するもの

流れ

  • 送信側:ディジタル署名にディジタル証明書を含み、一緒に送る
  • 受信側:認証局に問い合わせ。証明書が正当なら署名を復号
しみゆーしみゆー

ディジタル証明書

  • サーバー証明書:サーバーの認証に用いる証明書
  • クライアント証明書:クライアント側の認証に用いる証明書

ルート証明書

  • ルート認証局が発行した自分自身の身元証明をする証明書
    • 下位にあたるサーバー証明書やクライアント証明書は、エンドエンティティ証明書にあたる

ルート認証局

公的な認証局や企業が運営しており、かなり厳しい審査を受けた合格したところだけが名乗れる。
そもそもルート認証局が信用できなければディジタル証明書自体が成り立たない。

  • Microsoft、日本ではSECOMなど

階層構造

  • ルート認証局の下に子、孫と下位の認証局がある、いわゆる階層構造になっている。
  • 下位の認証局は、1つ上の認証局に証明書を発行してもらう。
  • ルート認証局が唯一自分自身に対してディジタル証明書を発行できる

ディジタル証明書を構成するもの

  • 署名前証明書
    • サーバーやその所有者に関する情報。有効期限や公開鍵など
  • ディジタル署名のアルゴリズム
  • ディジタル署名
    • 署名前証明書をハッシュ化し、それを認証局の秘密鍵で暗号化したもの

サーバー証明書の確認

  • 受信側:証明書内のディジタル署名を認証局の公開鍵で復号。
    • 署名前証明書と比較する。
    • 一致していたら証明書が改ざんされていないことが分かり、サーバーが本物だと分かる
      • 公開鍵で復号できるのは同じペアの秘密鍵で暗号化されたものだけ。秘密鍵は本物のサーバーしか持ってないので、その公開鍵で正しく復号できたらサーバーが秘密鍵を保持している本物のサーバーと分かる。
しみゆーしみゆー

公開鍵暗号方式

  • 公開鍵は知られても、そこから秘密鍵を推測することが困難
  • 公開鍵によって暗号化したものは、対となる秘密鍵でしか復号できない。
  • 秘密鍵によって暗号化したものは、対となる公開鍵でしか復号できない。
しみゆーしみゆー

インターネットの存在する危険

  • 事後否認
    • 送信側が後でそんなものを送信していないと言う
    • 証明によって防ぐ
  • 盗聴
    • 暗号化
  • なりすまし
    • 認証、本人確認、証明書
  • 改ざん
    • 電子署名