Help us understand the problem. What is going on with this article?

ちゃんと理解するSSL/TLS 前編

More than 3 years have passed since last update.

目的・概要

昨今、我々がInternet上のサービスを利用するにあたり、SSL/TLSは無くてはならない存在となっています。
なんとなく、おぼろげに理解しているSSL/TLSについて、仕組みをきちんと理解するに足る内容を整理し、
ポイントを押さえた説明を行うことを目的とします。

以下のような読者、具体的にはITエンジニア新人~2,3年目の方を対象としています。
何となくアプリ開発・インフラ開発は出来るようになったけれども、各要素技術の詳細について理解が曖昧という人を想定しています。

  • SSL/TLSを何となく理解しているが、これを利用する通信・その他技術について、順を追って説明することが出来ない。
  • OpenSSLのコマンドを打って何となくオレオレ証明書が作れたが、仕組みをよく理解していない。
  • 生成・削除・編集が容易な電子データなのに、何故、偽造が出来ない/改ざんが出来ないのか、ちゃんと説明することが出来ない。

この投稿は何ではないか

この投稿は以下を目的としていません。

  • 技術的に重要な要素を曖昧に、たとえ話で説明し、何となく分かった気にさせる
  • OpenSSLのコマンドを紹介して、手っ取り早くCSR作成・秘密鍵作成する、SSLサーバ証明書を購入する手順を記載する
  • オレオレ証明書を作り、Webサーバ(Apache/nginx)にインストールする
  • SSL/TLSのプロトコル自体を詳解する

構成

情報量が多いので、前後編に分割します。

前編(この記事)は、SSL/TLSを実現する基礎的な仕組み・概念・技術要素を説明します。
後編は、SSL/TLSの具体的な内容について説明します。

以前、社内の勉強会で利用したスライドをベースに作成したので、お見苦しいところがあります。

用語の定義

No 用語 説明・内容
1 SSL/TLS Internet上でセキュアな通信を行うためのプロトコルの一つ。本記事で説明するもの。歴史的な経緯から、SSL/TLSには複数のバージョンがあるが、ここではそれらを総称して呼称する。
2 SSLサーバ証明書 Internet上で運営するWebサーバの正統性を証明するもの。本記事では「サーバ証明書」とも記述することがある。
3 平文 暗号化されていない文字列・情報。
4 暗号文 平文を、事前に既定した暗号方式で暗号化したもの。第三者に見られても、内容を読み取れない。
5 暗号化 平文を、既定の暗号方式に従って暗号文に変換すること。
6 復号化 暗号文を、既定の暗号方式に従って平文に変換すること。単に「復号」とも。
7 検証 電子署名を元に、対象となる電子データが改ざんされていない正当なものであることを、既定の手順に従って確認すること。

なぜ暗号が必要なのか

セキュリティの三要素

  • 通信相手以外が通信内容を見ても、内容を判別できないようにしたい(Confidentiality)
  • 通信内容が途中で改ざんされないようにしたい/改ざんされたらそれが分かるようにしたい(Integrity)
  • 通信内容は予め許可した人にだけ参照可能なようにしたい(Availability)

暗号はConfidentialityを担保する。

共通鍵暗号と公開鍵暗号

共通鍵暗号方式

  • 文字列の暗号化・復号化に同じ鍵を用いる方式
  • 鍵を安全に渡すことが難しい
  • 仕組みがシンプル スライド9.PNG

公開鍵暗号方式の仕組み

  • 暗号化・復号化に別の鍵を用いる方式
  • 2つの鍵を「鍵ペア」と呼び、それぞれ「秘密鍵」 「公開鍵」と呼ぶ
  • 下記例では、「秘密鍵A」と「公開鍵A」が「鍵ペア」となる
  • 秘密鍵で暗号化した文字列は、対になる公開鍵でのみ復号できる
  • 公開鍵で暗号化した文字列は、対になる秘密鍵でのみ復号できる スライド10.PNG

なぜこのような芸当が実現できるのか、公開鍵そのものの仕組み・特性については、下記サイトが参考になります。
http://www.maitou.gr.jp/rsa/
http://www.maitou.gr.jp/rsa/rsa07.php

  • 下記2組の鍵ペアを利用した通信の例
    • 公開鍵W ・秘密鍵W(白ヤギさんが保持)
    • 公開鍵B・秘密鍵B (黒ヤギさんが保持)
  • 通信の流れ
    • 通信相手の公開鍵を利用し、送りたい平文を暗号化する。
    • 暗号文を受け取った側は、自分の秘密鍵で暗号文を復号する。
  • 通信に先立ち、相手の公開鍵を入手しておく必要がある。 スライド11.PNG

公開鍵暗号方式の難問

  • 手に入れた公開鍵が、通信を望む相手のものなのか証明できない。
  • 下図は、問題なく公開鍵の受け渡しができた場合。
    スライド12.PNG

  • 手に入れた公開鍵が、通信を望む相手のものなのか証明できない。

  • 下図は、中間に悪意の第三者が介在し、盗聴している場合。

  • 白ヤギさんは、受け取った公開鍵が黒ヤギさんのものなのかどうか、判別できない。

  • この後白ヤギさんが、公開鍵Xで暗号化したデータを送った場合、悪意の第三者に解読されてしまう。
    スライド13.PNG

  • 何が必要か

    • 通信相手の公開鍵が本当に当人のものなのか、証明する必要がある。
  • どうやるか

    • 公開鍵とその所有者の情報を組み合わせ、その内容に改ざんが無いことを証明する。
    • →電子署名 スライド14.PNG

電子署名

電子署名とは

  • 電子署名(でんししょめい)とは、電磁的記録(電子文書)に付与する、電子的な徴証であり、紙文書における印やサイン(署名)に相当する役割をはたすものである。主に本人確認、偽造・改竄(かいざん)の防止のために用いられる。
  • SSL/TLSにおいて利用される。

電子署名の構成要素

  • 公開鍵暗号方式(※説明済み)
  • ハッシュ関数(一方向関数)
  • 信頼できる第三者(CA局)
  • 電子署名/電子証明書

ハッシュ関数(一方向関数)

  • 入力文字列に複雑な計算を行い、固定長の数字を出力する関数
  • 入力が1文字でも違えば出力は全く違うものになるため、改竄の検出に利用できる
  • 出力文字列のサイズは、概ね128bit/256bit/512bitなどが利用される
  • 主なハッシュ関数に以下のようなものがある
    • SHA-2
    • SHA-1
    • MD5(脆弱性があるため、近年では利用されないようになっている) スライド17.PNG

信頼できる第三者(CA局)

  • ある電子データ(署名文書)の改竄が無いことを担保するための重要な主体
    • Certificate Authorityの略
    • 日本語では「認証局」とも呼ばれる。
  • CA局は厳重に管理された鍵ペアを運用する
    • CA局の公開鍵は事前に広く配布される
    • 鍵ペアを厳重に管理し、秘密鍵の漏洩は無いとされる
  • 電子署名≒CA局が保持する秘密鍵で暗号化されたデータ スライド18.PNG

電子署名/電子証明書

  • 通信主体の素性(署名文書)など、改ざんが無いことを保証したいデータに対し、CA局で電子署名を付与したもの
  • 電子署名は、扱いを容易にするため、署名文書をハッシュ化した文字列に対して暗号化が行われる スライド19.PNG

電子証明書の作成

黒ヤギさんの署名文書から、電子証明書を作成する手順を考える。

  1. 黒ヤギさんが署名文書を作成し、CA局に署名を依頼する。この文書の中に、黒ヤギさんの公開鍵「公開鍵B」を入れておく
  2. CA局は、署名文書をハッシュ化する。
  3. ハッシュ化して得られた文字列を、CA局の秘密鍵で暗号化する。これが電子署名となる。(これはCA局の公開鍵でのみ、復号できる)
  4. 1.の署名文書に、3.で得られた文字列を付加したものが「電子証明書」となる。これを黒ヤギさんに返す。 スライド20.PNG

電子証明書の検証

白ヤギさんが、黒ヤギさんの電子証明書を検証する手順を考える。

  1. 白ヤギさん黒ヤギさんから電子証明書を受け取る
  2. 白ヤギさんは、電子証明書の署名文書部分をハッシュ化する。
  3. 白ヤギさんは、電子署名部分をCA局の公開鍵「公開鍵CA」で復号化する(これは事前に入手している)
  4. 2.と3.で得られた文字を比較し、両者に差が無ければ、署名文書に改竄が無いと判断できる。結果、公開鍵Bが正統なものであることを確認できる。 スライド21.PNG

電子署名の難問

  • CA局の公開鍵はどうすれば信用できるのか?
  • 更に上位のCA局が、下位のCA局の公開鍵・情報を証明すれば良いのか?
    • →どこまでもさかのぼって際限が無い。どこかで割り切りが必要

電子署名が成り立つためのポイント

  • 信頼できる第三者がCA局として存在する
  • CA局の公開鍵を、信用できる手段で予め入手しておく

→上記が成り立たなければ、電子署名が成り立たない

SSL/TLSの場合、どう実現しているか?

  • Symantec社やThawte社など、信頼のおける会社がCA局を運営している
  • Webブラウザ出荷時に、予めCA局の公開鍵を「ルート証明書」として組み込んでおく。Internet Explorerの場合は、「信頼されたルート証明機関」として管理されている。

※後編に続く

tmiki
Tech Fun株式会社( http://www.techfun.co.jp/ )所属のエンジニア。10年ぐらいインフラエンジニア、ここ数年はアプリエンジニア。 好きな言語はDartとゲール語とサンスクリット語、好きなAWSサービスはIAM/STSです。 本サイトで投稿する内容は個人の見解に基づくものであり、所属組織の意向に関わるものではありません。
techfun
Tech FunはITの力で世界を豊かにする総合サービス企業です。 IT研修スクール「TechFun.jp(https://techfun.jp/)」、eラーニングプラットフォーム「StudySmile(https://studysmile.com/)」のほか、ミャンマーオフショア開発、スマートフォンアプリ開発、Webシステム開発、SIサービスを展開しています。
https://www.techfun.co.jp/
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした