Embed Size (px)
Citation preview
2019/6/18 2
今日の内容
◼ 暗号化を用いた技術
◼ SSL
◼ S/MIME
2019/6/18 3
SSLとは
インターネット上で情報を暗号化して通信するためのプロトコル
Ethernetなど
IP
TCP/UDP
SSL
HTTP FTP TELNET
Ethernetなど
IP
TCP/UDP
HTTP FTP TELNET
Secure Socket Layerの略
2019/6/18 4
SSLの利用
https:で始まるURL
鍵マーク
2019/6/18 5
共通鍵暗号による通信
SSLでは，共通鍵暗号を用いて通信を行う
公開鍵暗号は処理に時間がかかる
どうやって安全に鍵を渡すか
2019/6/18 6
SSLのしくみ
クライアントがサーバに要求を送信する
秘密鍵
通信するから鍵をくれ
2019/6/18 7
SSLのしくみ
サーバはクライアントに証明書付きの鍵（サーバ証明書）を送る
A社の公開鍵であることを証明します
認証
局印
秘密鍵
2019/6/18 8
SSLのしくみ
クライアントはサーバの証明書をチェックする
A社の公開鍵であることを証明します
認証
局印
本物？秘密鍵
2019/6/18 9
SSLのしくみ
本物であることが確認されたら，クライアントはサーバの公開鍵を用いて，通信に用いる共通鍵（セッション鍵）を暗号化
A社の公開鍵であることを証明します
認証
局印
2kwh91jH8J53j (h1k&914h ^&*^秘密鍵
2019/6/18 10
SSLのしくみ
クライアントは暗号化したセッション鍵をサーバに送る
2kwh91jH8J53j (h1k&914h ^&*^
セッション鍵 秘密鍵
2019/6/18 11
SSLのしくみ
サーバは受け取ったデータを自分の秘密鍵で復号→セッション鍵を得る
セッション鍵
2kwh91jH8J53j (h1k&914h ^&*^
秘密鍵
2019/6/18 12
SSLのしくみ
共通のセッション鍵を用いて暗号化通信を行う
セッション鍵
実は
2019/6/18 13
今の説明はちょっと省略している部分があります
暗号化と圧縮
2019/6/18 14
SSLでは暗号化とともに圧縮もやっている
複数の暗号化手法
複数の圧縮手法 を利用できる
クライアントとサーバの間でどの手法を用いるか合意をとる必要がある
共通鍵は送らない
2019/6/18 15
通信に使う共通鍵は，実際にはネットワーク上を流れることはない
2019/6/18 16
SSLのしくみ
クライアントがサーバに要求を送信する際に
秘密鍵
通信するから鍵をくれ
利用可能な暗号化手法と圧縮手法の一覧クライアントで適当（ランダム）に作った数を一緒に送信する
暗号化メニュー手法A手法B圧縮メニュー手法X手法Y
176389
176389
作った数は覚えておく
2019/6/18 17
SSLのしくみ
サーバはクライアントに証明書付きの鍵（サーバ証明書）を送る
A社の公開鍵であることを証明します
認証
局印
秘密鍵
834762
176389
暗号化手法と圧縮手法サーバ側でランダムに作った数を一緒に送信する
834762
受信した数と今作った数を覚えておく
176389
暗号化は手法A圧縮は手法Xで行きましょう
2019/6/18 18
SSLのしくみ
クライアントはサーバの証明書をチェックする
A社の公開鍵であることを証明します
認証
局印
本物？秘密鍵
834762
176389
176389
834762
2019/6/18 19
SSLのしくみ
本物であることが確認されたら，クライアントはサーバの公開鍵を用いて，ランダムに作った別の数を暗号化
A社の公開鍵であることを証明します
認証
局印
2kwh91jH8J53j (h1k&914h ^&*^秘密鍵
755398
834762
176389
176389
834762
2019/6/18 20
SSLのしくみ
クライアントは暗号化した数をサーバに送る
2kwh91jH8J53j (h1k&914h ^&*^
秘密鍵
755398
834762
176389
176389
834762
2019/6/18 21
SSLのしくみ
サーバは受け取ったデータを自分の秘密鍵で復号→もとの数を得る
2kwh91jH8J53j (h1k&914h ^&*^
秘密鍵
755398
834762
176389
176389
834762
755398
2019/6/18 22
SSLのしくみ
•クライアントが最初に送った数•サーバが送った数•クライアントが後で送った数
セッション鍵
755398
176389 834762
サーバ，クライアント両方で
をもとに通信に用いる共通鍵（セッション鍵）を作成
2019/6/18 23
SSLのしくみ
共通のセッション鍵を用いて暗号化通信を行う
セッション鍵
2019/6/18 24
S/MIME
電子メールの暗号化方式の標準
PKIのしくみを利用している
暗号化
電子署名
特に目新しい話はありません．．．
Secure MIMEの略
2019/6/18 25
余談：MIMEとは
Multipurpose Internet Mail Extensionsの略
電子メールで各国語や画像，音声などを扱うための規格
そもそもなぜこんなものが必要なのか？
そこにはインターネットと電子メールの長い歴史がある
2019/6/18 26
電子メールは英語だけ？
電子メールはもともと英語の文章をやりとりすることを前提としていた
電子メールシステムは英語の文字しか扱うことができない
2019/6/18 27
ASCIIコード
アルファベットといくつかの記号（コンマ，ピリオドなど）と制御文字（スペース，タブなど）に0から127の数字が割り当てられている
7ビット（7つの0と1）で表される
英語の文章は7ビットの列で表される
1100001 1100010 1100011
“abc”
01100001 01100010 01100011
8ビット単位で送る場合は
2019/6/18 28
メールに歴史あり
01100001 01100010 01100011
8ビット単位で送る場合
最上位ビットは無視
昔のインターネットには7ビット単位で情報を送っていたネットワークが含まれていた
電子メールでは「7ビット単位で情報を転送する」と決められた
英語の文章だけを送ることを想定して作られたネットワーク
2019/6/18 29
メールサーバのふるまい
11100001 11100010 11100011
abcだな
01100001 01100010 01100011
たとえ8ビット単位でデータが送られてきても
8ビットの最上位ビットがきちんと転送されない→下位7ビットだけで情報をやりとりする必要がある
2019/6/18 30
日本語メールの文字コード
日本語にはいくつかの文字コードがあるが7ビットの列で表されるコードはただ1つ
ISO-2022-JP
インターネットメールで日本語を使う場合はこのコードを使うよう決められている
ほとんどJISコードと同じ
唯一の違いは「半角カナ」を含まないこと
2019/6/18 31
半角カナが嫌われる理由
半角カナは「禁断の8ビット目」を利用しているため，ISO-2022-JPからは除外されている
半角カナの入ったメールは文字化けすることが多い
ﾊﾝｶｸｶﾅﾑｶﾂｸ!
半角カナの入ったメールをどう処理するかはソフトによってばらばら
2019/6/18 32
文字以外のデータ
そんなわけで，電子メールでは8ビットの最上位ビットをきちんと転送しない
画像
音声
他の文字コードの日本語（Shift-JIS,EUCなど）
これらのデータは本来電子メールでは送れない
2019/6/18 33
MIMEの働き
MIMEは，これらのデータをメールでやりとりできるように，変換，復元するためのしくみ
情報を7ビットの列として表す
実際には8ビット単位（最上位ビットは0）で送る
ファイルのサイズが大きくなる→メールの添付ファイルで送るのはそもそも効率が悪い
2019/6/18 34
MIMEで変換されたデータ
Content-Type: application/pdf; name="=?iso-2022-jp?B?GyRCO3Y2SEZiRGo9cRsoQi5wZGY=?="Content-Transfer-Encoding: base64Content-Disposition: attachment; filename="=?iso-2022-jp?B?GyRCO3Y2SEZiRGo9cRsoQi5wZGY=?="
JVBERi0xLjQKJRamipIKNCAwIG9iago8PC9UeXBlL1hPYmplY3QKL1N1YnR5cGUvSW1hZ2UKL1dpZHRoIDE2NTYKL0hlaWdodCAyMzM5Ci9CaXRzUGVyQ29tcG9uZW50IDEKL0NvbG9yU3BhY2UvRGV2aWNlR3JheQovRmlsdGVyIC9DQ0lUVEZheERlY29kZQovRGVjb2RlUGFybXMgPDwvQ29sdW1ucyAxNjU2IC9Sb3dzIDIzMzk+PgovTGVuZ3RoIDQ0NDM1Cj4+CnN0cmVhbQoAFNLIAKaWQAU0sgAppZABTSyACmlkAFNLIAKaWQAU0sgAppZABTSyACmlkAFNLIAKaWQAU0sgAppZABTSyACmlkAFNLIAKaWQAU0sgAppZABTSyACmlkAFNLIAKaWQAU0sgAppZABTSyACmlkAFNLIAKaWQAU0sgAppZABTSyACmlkAFNLIAKaWQAU0sgAppZABTSyACmlkAFNLIAKaWQAU0sgAppZABTSyACmlkAFNLIAKaWQAU0sgAppZABTSyACmlkAFNLIAKaWQAU0sgAppZABTSyACmlkAFNLIAKaWQAU0sgAppZABTSyACmlkAFNLIAKaWQAU0sgAppZABTSyACmlkAFNLIAKaWQAU0sgAppZABTSyACmlkAFNLIAKaWQAU0sgAppZABTSyACmlkAFNLIAKaWQAU0sgAppZABTSyACmlkAFNLIAKaWQAU0sgAppZABTSyACmlkAFNLIAKaWQAU0sgAppZABTSyACmlkAFNLIAKaWQAU0sgAppZABTSyACmlkAFNLIAKaWQAU0sgAppZABTSyACmlkAFNLIAKaWQAU0sgAppZABTSyACmlkAFNLIAKaWQAU0sgAppZABTSyACmlkAFNLIAKaWQAU0sgAppZABTSyACmlkAFNLIAKaWQAU0sg
すべてASCII文字からなるのが特徴
2019/6/18 35
まとめ
◼ 暗号化を用いた技術
◼ SSL
◼ S/MIME
参考（？）リンク
2019/6/18 36
http://www.atmarkit.co.jp/fnetwork/rensai/cell02/ssl3.html
http://www.ipa.go.jp/security/pki/071.html
2019/6/18 37
おまけ
◼ 実際にパケットが暗号化される様子を見てみよう
