【2025改訂版】ITエンジニアとして知っておいてほしい、電子メールという大きな穴

2025/11/29 セキュリティ・キャンプ2025ミニ（石川開催） 専門講座にて講義をした際の資料です。

途中出てくるハンズオンの資料は、こちらからアクセスしてください。
https://github.com/logica0419/seccamp-mini-ishikawa2025

1. Takuto Nagami @logica0419 ITエンジニアとして 知っておいてほしい 電子メールという 大きな穴 【2025改訂版】
2. 講師自己紹介 • 永見 拓人 (@logica0419) • 千葉工業大学 情報科学部 情報ネットワーク学科 4年 ◦ 研究: 分散DB (etcd/Raft) × 暗号 (秘密分散) • Go言語・Kubernetes周りにある程度詳しいです • セキュキャン歴 ◦ 2022 全国大会 修了 ◦ 2024/2025 全国大会 チューター ◦ 2024 ミニ (山梨) 講師
3. なぜ、今メールなのか
4. 「メールなんて今どき 使わないじゃん」と 思っていませんか？
5. サイバー犯罪検挙件数の推移 by 警察庁 平成28年～令和2年のもの
6. メールが何らかの形で絡んでいるものは どれでしょう？
7. メールが何らかの形で絡んでいるものは どれでしょう？
8. メールが何らかの形で絡んでいるものは どれでしょう？ 何気なく使っているメールは サイバー犯罪の温床！
9. なぜ電子メールは 様々なサイバー犯罪で 用いられるのだろうか？ そのためには、メールの現状を知る必要がある
10. 電子メールのおこり • 1965年頃から存在する ◦ 非常に長く使われている ◦ インターネットがない時代からある ◦ インターネットのもとになった技術の一つ • 現在の fuga@hogehoge.net のような形のアドレスが 使われ始めたのは、1971年から • 1980年代以降に、RFCとして送受信方法の共通化が 行われた
11. 電子メールの特徴 • 特定のサービス等に依存しない ◦ ここがSNSとは違う • プライベートな 1対1 or 1対多 の通信 ◦ Webサイト等とは少し別の技術 • 非常に広く用いられる ◦ メールアドレスを持たない人、周りでいますか？ ◦ 多くのサイトでログインに使用する ◦ 企業同士のやり取りは、多くが電子メール
12. 電子メールのセキュリティ懸念 • 単純に広く使われているので、犯罪に使いやすい ◦ ターゲットが多いので、数打て戦法が有効に ◦ SNSをあまり見ない高齢者や企業さえ標的にできる • インターネットの起こり時代に定められた、非常に脆弱 で機能が少ない仕組みで送られている ◦ 素の状態では送信元偽装・改ざんとかし放題 ◦ ≓ Secure by Defaultでない ▪ ただ使っているだけで安全、とはならない
13. サイバー犯罪検挙件数の推移 by 警察庁 メールはどのように絡んでいるのか
14. サイバー犯罪検挙件数の推移 by 警察庁 メールはどのように絡んでいるのか • フィッシングメールで パスワードを奪う • 警告メールを装ってアカウント リセットを強要しアカウントを 乗っ取る
15. サイバー犯罪検挙件数の推移 by 警察庁 メールはどのように絡んでいるのか • メールの添付ファイルでマル ウェアを送り付ける • メールを媒介として広がって いくウイルスを作成
16. サイバー犯罪検挙件数の推移 by 警察庁 メールはどのように絡んでいるのか • フィッシングメール • 送り主を大手サービスだと偽り お金を払わせる • 家族のふりをしてメールを出し オレオレ詐欺をする
17. 様々な犯罪に絡んでしまう 電子メールを 学ぶことは大事！ 自分たちが使わないからこそ、狙われることも
18. アジェンダ • なぜ、今メールなのか • プロトコルスタックとRFC • メールが送られる仕組み • SMTPプロトコル • ハンズオン - 「SMTPを手書きしてみよう！」 • SMTPを安全にするための仕組み • ハンズオン - 「メールのソースを見てみよう！」 • メールとの向き合い方
19. アジェンダ • なぜ、今メールなのか • プロトコルスタックとRFC • メールが送られる仕組み • SMTPプロトコル • ハンズオン - 「SMTPを手書きしてみよう！」 • SMTPを安全にするための仕組み • ハンズオン - 「メールのソースを見てみよう！」 • メールとの向き合い方
20. プロトコルスタックとRFC
21. プロトコル • コンピューター同士が通信する時の約束事 ◦ どんなデータを渡す必要があるか ◦ どんな順番でデータを渡すか ◦ それぞれのデータはどんなサイズか ◦ …などなど • 人間界の「言語」と同じもの • 世界中のあらゆる機器 (どんな企業製でも) が相互通信 できるインターネットを作るのに必要不可欠
22. プロトコル プロトコルを使って「会話」する プロトコル
23. プロトコル プロトコルが無いと… 言ってることが わからないので、 通信できない！
24. プロトコルは、通信の 「カオス」を解決してくれる 素晴らしい仕組み プロトコルという仕組みに感謝しよう
25. プロトコルスタック 様々なプロトコルを、積み重ねてひとまとめにしたもの
26. なぜ「積み重ねる」(階層化する) のか • 通信に必要な知識は膨大 ◦ 極論を言えばみんなが指から電気信号を出して通信 しなければいけなくなる ◦ 人間に分かりやすくするため / あらゆる場面に対応 するために、様々な知識が必要 • 関心の分離をし、専門分野を分ける ◦ LANケーブルを扱う人と、Webページを作る人は 一緒ではない
27. OSI参照モデル 今のインターネットを支えるプロトコルの、よく使われる 階層分け方法 7 アプリケーション層 6 プレゼンテーション層 5 セッション層 4 トランスポート層 3 ネットワーク層 2 データリンク層 1 物理層
28. 階層ごとの役割 7 アプリケーション層 アプリケーション間のやり取り 6 プレゼンテーション層 データの表現形式 5 セッション層 接続の手順 4 トランスポート層 データ通信の制御 3 ネットワーク層 インターネットワークでの通信 2 データリンク層 同一ネットワーク上での通信 1 物理層 ケーブルや電気信号やコネクタなど
29. インターネットはこれらの頑張りによる奇跡の産物 それぞれの階層でプロトコルを 守ることで、インター ネットは成り立っている
30. プロトコルを決める過程 - RFC • RFC (Request for Comments) ◦ インターネットにおけるプロトコルの仕様書のこと • RFCのフェーズ ◦ Internet Draft - 仕様を煮詰める ◦ Proposed Standard - 標準化すべきと認められた ◦ Draft Standard - 多くの機器で使える ◦ Standard - インターネットで広く使われる • 「決めてから普及」ではなく、「普及したら標準」
31. プロトコルを決める過程 - RFC • IETFという団体で議論され、標準化される • 思想 ◦ オープンである - Request for “Comments” ▪ RFCはメーリングリストで決まる ◦ 仕様よりも実装重視 ▪ RFCのフェーズも、この思想の下にある • 内容は改定できない ◦ 新しいRFCの発行と、古いRFCの無効化で変更
32. RFCの例 - http https://www.rfc-editor.org/rfc/rfc9110.html で公開
33. インターネットが好きなら 是非プロトコルスタックと RFCを理解して使おう！ 「RFCを読む会」なんてイベントもあるそう
34. アジェンダ • なぜ、今メールなのか • プロトコルスタックとRFC • メールが送られる仕組み • SMTPプロトコル • ハンズオン - 「SMTPを手書きしてみよう！」 • SMTPを安全にするための仕組み • ハンズオン - 「メールのソースを見てみよう！」 • メールとの向き合い方
35. アジェンダ • なぜ、今メールなのか • プロトコルスタックとRFC • メールが送られる仕組み • SMTPプロトコル • ハンズオン - 「SMTPを手書きしてみよう！」 • SMTPを安全にするための仕組み • ハンズオン - 「メールのソースを見てみよう！」 • メールとの向き合い方
36. メールが送られる仕組み
37. hoge@gmail.com から fuga@icloud.com への メール送信を図解してみる メールが送られる仕組みを理解しよう
38. 登場人物たち ユーザー メールサーバー DNSサーバー
39. インターネット ユーザーが送信する (サブミッション) Gmail iCloud
40. インターネット ユーザーが送信する (サブミッション) Gmail iCloud サブミッション
41. メールサーバー • メールの 送信 / 受信 / 保存 全てを執り行う • メールの受信 ◦ あらゆるメールを受け取る ◦ 自分宛のメールならユーザーごとの メールボックスに保存し、提供する • メールの送信 ◦ 自分宛でなければ正しい宛先に届ける ◦ リレーと呼ばれる
42. インターネット 宛先に届ける (リレー) Gmail iCloud サブミッション
43. インターネット 宛先に届ける (リレー) Gmail iCloud サブミッション リレーしたい…！
44. インターネット でも、iCloudのサーバーの場所が不明… Gmail iCloud サブミッション ？ ？ ？
45. IPアドレスとドメイン名 • IPアドレス ◦ インターネットでそれぞれの機器が一意に持つ住所 • ドメイン名 ◦ IPアドレスは数字でわかりづらいので、これを わかりやすい文字列で表せるようにしたもの ◦ https://www.security-camp.or.jp/ ◦ info@security-camp.or.jp ▪ 実はメールアドレスにもドメインは入ってる！
46. DNSサーバー • ドメイン名とIPアドレスを紐付けるための仕組みを 提供する ◦ これ無しでドメイン名は成り立たない • おまけ機能として、ドメイン名と任意の テキストデータを紐づける仕組みも 提供している ◦ これが、メールを安全にするための プロトコルで活躍する
47. インターネット DNSに問い合わせ Gmail iCloud サブミッション iCloudドメインを問い合わせ
48. インターネット DNSに問い合わせ Gmail iCloud サブミッション iCloudドメインを問い合わせ iCloudサーバーのIPアドレス
49. インターネット 宛先に届ける (リレー) Gmail iCloud サブミッション iCloudドメインを問い合わせ iCloudサーバーのIPアドレス リ レ ー
50. インターネット iCloudがメールを受信 Gmail iCloud サブミッション iCloudドメインを問い合わせ iCloudサーバーのIPアドレス リ レ ー
51. インターネット ユーザーが受信したメールを見る Gmail iCloud サブミッション iCloudドメインを問い合わせ iCloudサーバーのIPアドレス リ レ ー 閲覧
52. インターネット ユーザーが受信したメールを見る Gmail iCloud サブミッション iCloudドメインを問い合わせ iCloudサーバーのIPアドレス リ レ ー 閲覧 受信したメールを見る部分 (POP / IMAP) は詳細を割愛
53. インターネット 今一度全体像を俯瞰してみよう Gmail iCloud サブミッション iCloudドメインを問い合わせ iCloudサーバーのIPアドレス リ レ ー 閲覧
54. アジェンダ • なぜ、今メールなのか • プロトコルスタックとRFC • メールが送られる仕組み • SMTPプロトコル • ハンズオン - 「SMTPを手書きしてみよう！」 • SMTPを安全にするための仕組み • ハンズオン - 「メールのソースを見てみよう！」 • メールとの向き合い方
55. アジェンダ • なぜ、今メールなのか • プロトコルスタックとRFC • メールが送られる仕組み • SMTPプロトコル • ハンズオン - 「SMTPを手書きしてみよう！」 • SMTPを安全にするための仕組み • ハンズオン - 「メールのソースを見てみよう！」 • メールとの向き合い方
56. SMTPプロトコル
57. インターネット メールを成り立たせている操作 Gmail iCloud サブミッション iCloudドメインを問い合わせ iCloudサーバーのIPアドレス リ レ ー 閲覧
58. インターネット 一番大事な部分を支えるのが、SMTP！ Gmail iCloud サブミッション iCloudドメインを問い合わせ iCloudサーバーのIPアドレス リ レ ー 閲覧 SMTP SMTP DNS POP / IMAP
59. SMTPとは • SMTP (Simple Mail Transfer Protocol) ◦ メールの送信に特化したプロトコル ◦ 1982年に制定され、大枠は今も変わっていない • 対話型のプロトコル ◦ httpは、行って帰ってきたら終わり ▪ 「ページのデータ下さい」「はい」で表示 ◦ 自分の情報 / メールの情報を一つずつ渡し、それ ぞれに対してサーバーが応答を返す
60. プロトコルとしての立ち位置 • OSI参照モデルの中では以下の二つに位置する ◦ 7: アプリケーション層 ◦ 6: プレゼンテーション層 ◦ 「メール」というデータの表現の仕方と、メールの 送受信についてをどちらも定義している • プロトコルとして ◦ TCP (4: トランスポート層) の上のプロトコル ◦ 関連プロトコルがたくさんある (後述)
61. SMTPの大まかな流れ 送信側 受信側
62. SMTPの大まかな流れ 送信側 受信側 自己紹介 (HELO)
63. SMTPの大まかな流れ 送信側 受信側 自己紹介 (HELO) OK
64. SMTPの大まかな流れ 送信側 受信側 自己紹介 (HELO) OK 送り主 (MAIL FROM)
65. SMTPの大まかな流れ 送信側 受信側 自己紹介 (HELO) OK 送り主 (MAIL FROM) OK
66. SMTPの大まかな流れ 送信側 受信側 自己紹介 (HELO) OK 送り主 (MAIL FROM) OK 宛先 (RCPT TO)
67. SMTPの大まかな流れ 送信側 受信側 自己紹介 (HELO) OK 送り主 (MAIL FROM) OK 宛先 (RCPT TO) OK
68. SMTPの大まかな流れ 送信側 受信側 自己紹介 (HELO) OK 送り主 (MAIL FROM) OK 宛先 (RCPT TO) OK 内容 (DATA)
69. SMTPの大まかな流れ 送信側 受信側 自己紹介 (HELO) OK 送り主 (MAIL FROM) OK 宛先 (RCPT TO) OK 内容 (DATA) OK
70. SMTPの大まかな流れ 送信側 受信側 自己紹介 (HELO) OK 送り主 (MAIL FROM) OK 宛先 (RCPT TO) OK 内容 (DATA) OK 終了 (QUIT)
71. SMTPの大まかな流れ 送信側 受信側 自己紹介 (HELO) OK 送り主 (MAIL FROM) OK 宛先 (RCPT TO) OK 内容 (DATA) OK 終了 (QUIT) OK
72. SMTPの大まかな流れ 送信側 受信側 自己紹介 (HELO) OK 送り主 (MAIL FROM) OK 宛先 (RCPT TO) OK 内容 (DATA) OK 終了 (QUIT) OK しかも、これ全部 テキスト形式のやり取り！ (0101… ではない)
73. 自分でも書けそうな 気がしてきたでしょ？
74. 出来ます。 やりましょう。
75. アジェンダ • なぜ、今メールなのか • プロトコルスタックとRFC • メールが送られる仕組み • SMTPプロトコル • ハンズオン - 「SMTPを手書きしてみよう！」 • SMTPを安全にするための仕組み • ハンズオン - 「メールのソースを見てみよう！」 • メールとの向き合い方
76. アジェンダ • なぜ、今メールなのか • プロトコルスタックとRFC • メールが送られる仕組み • SMTPプロトコル • ハンズオン - 「SMTPを手書きしてみよう！」 • SMTPを安全にするための仕組み • ハンズオン - 「メールのソースを見てみよう！」 • メールとの向き合い方
77. ハンズオン 「SMTPを手書きしてみよう！」
78. 別でハンズオン資料を 用意してありますので、 それに従って進めて下さい！ https://github.com/logica0419/ seccamp-mini-ishikawa2025/blob/main/handson-1.md
79. • サーバーのIPアドレス ◦ 163.43.70.121 • ログインパスワード ◦ ishikawa2025 https://github.com/logica0419/ seccamp-mini-ishikawa2025/blob/main/handson-1.md
80. アジェンダ • なぜ、今メールなのか • プロトコルスタックとRFC • メールが送られる仕組み • SMTPプロトコル • ハンズオン - 「SMTPを手書きしてみよう！」 • SMTPを安全にするための仕組み • ハンズオン - 「メールのソースを見てみよう！」 • メールとの向き合い方
81. アジェンダ • なぜ、今メールなのか • プロトコルスタックとRFC • メールが送られる仕組み • SMTPプロトコル • ハンズオン - 「SMTPを手書きしてみよう！」 • SMTPを安全にするための仕組み • ハンズオン - 「メールのソースを見てみよう！」 • メールとの向き合い方
82. SMTPを安全にするための仕組み
83. SMTPというプロトコル、 素の状態では大量の 危険にさらされている ハンズオンで体感してもらえたはず
84. インターネット メールで起こり得る危険 Gmail iCloud サブミッション iCloudドメインを問い合わせ iCloudサーバーのIPアドレス リ レ ー 閲覧
85. インターネット メールで起こり得る危険 Gmail iCloud サブミッション iCloudドメインを問い合わせ iCloudサーバーのIPアドレス リ レ ー 閲覧 なりすまし
86. インターネット メールで起こり得る危険 Gmail iCloud サブミッション iCloudドメインを問い合わせ iCloudサーバーのIPアドレス リ レ ー 閲覧 なりすまし なりすまし
87. インターネット メールで起こり得る危険 Gmail iCloud サブミッション iCloudドメインを問い合わせ iCloudサーバーのIPアドレス リ レ ー 閲覧 傍 受 ・ 改 ざ ん
88. インターネット メールで起こり得る危険 Gmail iCloud サブミッション iCloudドメインを問い合わせ iCloudサーバーのIPアドレス リ レ ー 閲覧 傍受・改ざん
89. インターネット メールで起こり得る危険 Gmail iCloud サブミッション iCloudドメインを問い合わせ iCloudサーバーのIPアドレス リ レ ー 閲覧 フィッシングなど
90. 対策は2つ • プロトコル ◦ プロトコル (仕様) としてセキュリティ対策を定義 ◦ 広く使ってもらいやすい ◦ 汎用的でなければいけないため、効力が薄いことも • メールサーバー独自の対策 ◦ メールサーバーが独自に対策を実装 ◦ 目的に特化させやすい ◦ 実装依存なため、統一化はしにくい
91. 脅威への対策プロトコル ～ユーザーなりすまし編
92. インターネット このタイプのなりすまし Gmail iCloud サブミッション iCloudドメインを問い合わせ iCloudサーバーのIPアドレス リ レ ー 閲覧 なりすまし
93. POP before SMTP
94. インターネット ユーザーが送信する (サブミッション) Gmail iCloud サブミッション
95. インターネット …の前に Gmail iCloud 閲覧
96. インターネット からの Gmail iCloud 閲覧 サブミッション
97. Pop before SMTP • 「受信できる人間はこのメールサーバーの利用者だね」 問う考え方に基づく ◦ 自分が受信できるメールアドレスを持っていれば、 メールサーバを利用できる • Fromの書き換えを検知する仕組みではないので、なり すましの強固な予防策とはならない • この後のSMTP AUTHの方がよく使われているので マイナーなプロトコル
98. SMTP AUTH (SASL認証)
99. インターネット ユーザーが送信する (サブミッション) Gmail iCloud サブミッション
100. インターネット …の前に Gmail iCloud 認証 ユーザ名・パスワード
101. インターネット からの Gmail iCloud 認証 ユーザ名・パスワード サブミッション
102. SMTP AUTH • サブミッション前に、何らかの形でユーザー名とパス ワードをメールサーバーに送って認証 ◦ いわゆるアカウントの認証 • 認証情報の送り方によってタイプがある ◦ SMTP AUTH PLAIN - まとめる、弱い ◦ SMTP AUTH CRAM-MD5 - まとめる、強いが面倒 ◦ SMTP AUTH LOGIN - 2つをバラバラに、弱い
103. SMTP AUTH = SASL認証 • SASL (Simple Authentication and Security Layer) ◦ インターネットにおける、認証とセキュリティの ためのフレームワーク ◦ 基本的にどんなプロトコルとも組み合わせて使う ことができる • 紹介したもの以外にも、ワンタイムパスワードなどが サポートされている
104. OP25B
105. OP25B • リレー用ポートとサブミッション用ポートを分けよう！ という取り組み • リレーでいちいち認証は出来ない ◦ 全てのメールサーバーが、他の全てのサーバーへの 認証情報を持たなくてはいけなくなる • サブミッションは認証を必ずさせたい ◦ セキュリティを強制させたい
106. インターネット こうだったのを Gmail iCloud サブミッション iCloudドメインを問い合わせ iCloudサーバーのIPアドレス リ レ ー 閲覧 25番 25番
107. インターネット ちゃんと分けた Gmail iCloud サブミッション iCloudドメインを問い合わせ iCloudサーバーのIPアドレス リ レ ー 閲覧 25番 587番
108. インターネット サブミッションポートは堅牢にする Gmail iCloud iCloudドメインを問い合わせ iCloudサーバーのIPアドレス リ レ ー 閲覧 25番 サブミッション 587番
109. インターネット でもアクセスするポートさえ変えれば… Gmail iCloud iCloudドメインを問い合わせ iCloudサーバーのIPアドレス リ レ ー 閲覧 25番 リレーに 見せかけた サブミッション 25番
110. OP25B • 一般ユーザーに587番ポートしか使わせないために 最終的にISP (通信事業者) がインターネット経由で 25番ポートにアクセスする行為を封じた • 「OP25B」と調べると「外部の25番ポートへの接続を 出来ないようにする」という内容しか出てこない ◦ 背景情報をきちんと知ることで、初めてきちんと 理解できるタイプの取り組み
111. 脅威への対策プロトコル ～サーバー / ドメイン なりすまし編
112. インターネット このタイプのなりすまし Gmail iCloud サブミッション iCloudドメインを問い合わせ iCloudサーバーのIPアドレス リ レ ー 閲覧 なりすまし なりすまし
113. SPF (Sender Policy Framework)
114. インターネット 下準備 Gmail iCloud IPアドレス x.x.x.x
115. インターネット 下準備 Gmail iCloud Gmailのサーバーは x.x.x.xにあります！ IPアドレス x.x.x.x
116. おさらい: DNSサーバー • ドメイン名とIPアドレスを紐付けるための仕組みを 提供する • おまけ機能として、ドメイン名と任意の テキストデータを紐づける仕組みも 提供している ◦ これが、メールを安全にするための プロトコルで大活躍します
117. おさらい: DNSサーバー • ドメイン名とIPアドレスを紐付けるための仕組みを 提供する • おまけ機能として、ドメイン名と任意の テキストデータを紐づける仕組みも 提供している ◦ これが、メールを安全にするための プロトコルで大活躍します SPFにおいては、サーバーのIPを この「任意テキスト」として DNSに保存しておく
118. インターネット 受信後 Gmail iCloud サブミッション iCloudドメインを問い合わせ iCloudサーバーのIPアドレス リ レ ー Gmailのサーバーは x.x.x.xにあります！ IPアドレス x.x.x.x
119. インターネット 一致するか確かめる Gmail iCloud サブミッション iCloudドメインを問い合わせ iCloudサーバーのIPアドレス リ レ ー Gmailのサーバーは x.x.x.xにあります！ IPアドレス x.x.x.x
120. SPF (Sender Policy Framework) • DNSサーバーに正しいメールサーバーのアドレスを保存 しておくことで、受信後メールを送ってきたサーバーと 正しいメールサーバーのアドレスが一致するか確認 できるようにするプロトコル ◦ 不審なメールサーバーを検知できる • サーバー運用者の設定が面倒 • 間にサーバーが挟まってしまうと意味を成さない
121. DKIM (DomainKeys Identified Mail)
122. 前提知識: 公開鍵暗号 • 公開鍵 / 秘密鍵という、みんなに知られても良い鍵と 知られてはいけない鍵の2種類を用意する暗号化 ◦ cf. 共通鍵暗号 • 鍵 = 一定のルールで作られたランダムなテキスト • 特徴 ◦ 公開鍵で暗号化した文書は、秘密鍵でしか復号 できない
123. 特徴の部分をより分かりやすく図解 秘密鍵 (知られてはいけない) 公開鍵 (知られても良い)
124. 公開鍵暗号の使われ方 下準備 ← 必ずセットで作られる
125. 公開鍵暗号の使われ方 下準備 渡す
126. 公開鍵暗号の使われ方 下準備 渡す
127. 公開鍵暗号の使われ方 秘密鍵を持つ人しかわからないデータを作る (保護)
128. 公開鍵暗号の使われ方 秘密鍵を持つ人しかわからないデータを作る (保護) 受け手 送り手
129. 公開鍵暗号の使われ方 秘密鍵を持つ人しかわからないデータを作る (保護) 受け手 送り手
130. 公開鍵暗号の使われ方 秘密鍵を持つ人しかわからないデータを作る (保護) 受け手 送り手
131. 公開鍵暗号の使われ方 秘密鍵を持つ人しかわからないデータを作る (保護) 受け手 送り手 • 公開鍵で暗号化した文書は、 秘密鍵でしか復号できない
132. 公開鍵暗号の使われ方 秘密鍵を持つ人しかわからないデータを作る (保護) 受け手 送り手 渡す
133. 公開鍵暗号の使われ方 秘密鍵を持つ人しかわからないデータを作る (保護) 受け手 送り手
134. 逆転の発想: 署名 • 署名鍵 / 検証鍵という、みんなに知られても良い鍵と 知られてはいけない鍵の2種類を使って、正しい人が 作ったデータであることを確認する技術 • 特徴 ◦ 署名鍵で加工した文書 (署名) は、 検証鍵で必ず復号 できる • 初期のアイデアは公開鍵暗号の逆転だったが、そこから 独自に発展を遂げている
135. 特徴の部分をより分かりやすく図解 署名鍵 (知られてはいけない) 検証鍵 (知られても良い)
136. 署名の使われ方 送り主が署名鍵を持っているか確かめる (証明)
137. 署名の使われ方 送り主が署名鍵を持っているか確かめる (証明) 送り手 受け手
138. 署名の使われ方 送り主が署名鍵を持っているか確かめる (証明) 送り手 受け手
139. 署名の使われ方 送り主が署名鍵を持っているか確かめる (証明) 送り手 受け手 • 署名鍵で加工した文書 (署名) は 検証鍵で必ず復号できる
140. 署名の使われ方 送り主が署名鍵を持っているか確かめる (証明) 送り手 受け手 渡す
141. 署名の使われ方 送り主が署名鍵を持っているか確かめる (証明) 送り手 受け手
142. 署名の使われ方 送り主が署名鍵を持っているか確かめる (証明) 送り手 受け手 正しく復号できた = 正しい署名鍵で加工された データだとわかる！
143. 署名の使われ方 送り主が署名鍵を持っているか確かめる (証明) 送り手 受け手 これも暗号系の技術！ 「見れなくする」だけが 暗号じゃない
144. 本題のDKIM 署名鍵 検証鍵 を用意
145. インターネット 下準備 Gmail iCloud
146. インターネット 下準備 Gmail iCloud Gmailの検証鍵は これです！ DNSに登録
147. インターネット 送信後 Gmail iCloud サブミッション Gmailの検証鍵は これです！
148. インターネット メッセージを加工し署名に Gmail iCloud サブミッション Gmailの検証鍵は これです！
149. インターネット 受信後 Gmail iCloud サブミッション iCloudドメインを問い合わせ iCloudサーバーのIPアドレス リ レ ー Gmailの検証鍵は これです！
150. インターネット 署名を検証 Gmail iCloud サブミッション iCloudドメインを問い合わせ iCloudサーバーのIPアドレス リ レ ー Gmailの検証鍵は これです！ DNSか ら 取 得
151. インターネット 署名を検証 Gmail iCloud サブミッション iCloudドメインを問い合わせ iCloudサーバーのIPアドレス リ レ ー Gmailの検証鍵は これです！
152. DKIM • 署名鍵をメールサーバーに持ち、検証鍵をDNSで公開 しておく • 署名鍵でメール全体を加工したものを「署名」として メールに付けることで、正しいメールサーバーから 送られてきたことを保証する仕組み • サーバー運用者の設定が面倒 • サーバーを提供するサービス側の実装が面倒
153. DMARC (Domain-based Message Authentication Reporting and Conformance)
154. DMARC • SPF及びDKIMでメールサーバーが正しいと判定でき なかった時「どのようにメールを処理するか」を決める ことができるプロトコル ◦ 同じくDNSにポリシーとして定める • 「自分のドメインの成りすましが出た」という場合のみ 対処できる ◦ それ以外のパターンは考慮していない • サーバー運用者の設定が面倒
155. DMARCのポリシー • None ◦ メッセージは通常通り送信される ◦ 「DMARCレポート」がドメインの所有者に来る • Quarantine ◦ メッセージが別のフォルダに隔離される • Reject ◦ メッセージはその場で破棄される
156. DMARCまでやると、 現時点で「そのドメインは 安全」と言えるライン 自分でサーバーを運用するときは、ここまで設定すべし
157. BIMI (Brand Indicators for Message Identification)
158. 要はこれのこと
159. BIMI • DNSで、そのドメインからのメールに表示されるべき ブランドロゴを設定できるプロトコル ◦ どちらかというと企業とか向け ◦ Gmail / Yahooメールなどは表示してくれる • DMARCの検証が通って、初めて表示される • サーバー運用者の設定が面倒 • 受信するサービス側の実装が面倒
160. ARC (Authenticated Received Chain)
161. SPF・DKIM (・DMARC) の弱点 • 複数サーバーのリレー / メーリングリストなどで検証が うまく行かなくなることがある • SPF ◦ 検証時、送り元のサーバーは直前のサーバーのため • DKIM ◦ リレーの過程でヘッダが変更されることがある ◦ メーリングリストでもヘッダが変更される
162. ARC • リレーやメーリングリストに一斉転送する際、中間の サーバーでSPF・DKIMを検証して、その検証結果を メールに付けて次のサーバーに送る ◦ SPF・DKIMがダメならARCのヘッダを見る • 検証結果が偽造できないように、署名を付ける ◦ 署名はDKIMと全く同じ仕組みなのでDNSに追加の 設定をする必要ナシ
163. 脅威への対策プロトコル ～傍受・改ざん編
164. インターネット 傍受・改ざん Gmail iCloud サブミッション iCloudドメインを問い合わせ iCloudサーバーのIPアドレス リ レ ー 閲覧 傍 受 ・ 改 ざ ん
165. インターネット 傍受・改ざん Gmail iCloud サブミッション iCloudドメインを問い合わせ iCloudサーバーのIPアドレス リ レ ー 閲覧 傍受・改ざん
166. STARTTLS
167. STARTTLS • TLS (Transport Layer Security) をメールでも扱える ようにしたもの ◦ 「https」の「s」の技術 ◦ メール特有の技術ではない • サブミッション / リレーなど一つ一つの通信経路を 暗号化する • 悪意のあるメールサーバーが間に入った場合は対処 できない
168. MTA-STS (MTA Strict Transport Security)
169. MTA-STS • 認証 (SMTP AUTH) やSTARTTLSを、メールサーバー 利用者に強制することができるしくみ ◦ より強固なメールサーバーを作るために必要 • Gmailなどが導入している • DNSで「ポリシーがあるよ！」と宣言し、HTTPでポリ シー本体を公開する ◦ 設定のハードルが高い
170. OpenPGP・S/MIME (Secure / Multipurpose Internet Mail Extensions)
171. OpenPGP・S/MIME • エンド・ツー・エンドでメールを暗号化する仕組み ◦ 送信者が暗号化し、受信者が複合する • エンド・ツー・エンドでメールを署名する仕組み ◦ 送信者が署名し、受信者が検証する • 暗号化・署名で鍵を2ペア用意し、お互い鍵を持ち合う 面白いプロトコル
172. インターネット 下準備 Gmail iCloud
173. インターネット 鍵を準備 (暗号化サイド) Gmail iCloud
174. インターネット 鍵を準備 (暗号化サイド) Gmail iCloud 渡す
175. インターネット 鍵を準備 (署名サイド) Gmail iCloud
176. インターネット 鍵を準備 (署名サイド) Gmail iCloud 渡す
177. インターネット まず署名を作る Gmail iCloud
178. インターネット 続いて本文を暗号化 Gmail iCloud
179. インターネット 続いて本文を暗号化 Gmail iCloud なお、正確には共通鍵を混ぜた もっと複雑な暗号化ですが ここでは割愛します
180. インターネット 送信後、受信者の手元で Gmail iCloud サブミッション iCloudドメインを問い合わせ iCloudサーバーのIPアドレス リ レ ー 閲覧
181. インターネット まず本文を復号 Gmail iCloud サブミッション iCloudドメインを問い合わせ iCloudサーバーのIPアドレス リ レ ー 閲覧
182. インターネット 最後に署名を検証 Gmail iCloud サブミッション iCloudドメインを問い合わせ iCloudサーバーのIPアドレス リ レ ー 閲覧
183. インターネット 最後に署名を検証 Gmail iCloud サブミッション iCloudドメインを問い合わせ iCloudサーバーのIPアドレス リ レ ー 閲覧 改ざん対策の理想形だが 設定の複雑さが原因で 普及が進まない…
184. OpenPGP・S/MIMEの問題と解決法 • 検証鍵の信頼性が担保されない ◦ 本人のでなかったら、他人が署名してるのでマズい ◦ 暗号化は間違ってたら復号できないだけなので良い • OpenPGP ◦ 多くの人に信頼されている送信者は信頼 • S/MIME ◦ 認証局が信頼してるから信頼 ◦ 認証局にお金を払って、検証鍵を信頼してもらう
185. メールサービス独自の脅威対策
186. インターネット ユーザーなりすまし Gmail iCloud サブミッション iCloudドメインを問い合わせ iCloudサーバーのIPアドレス リ レ ー 閲覧 なりすまし
187. 送信メールアドレス制限 • 「自分が持っていること」が確認できるアドレスから しか送信できないようにする ◦ メールアドレス認証 ◦ ドメインを持っていることを証明する ▪ DNSに指定されたテキストを登録するなど • Gmailをはじめ、様々なメールサービスが導入している
188. インターネット メール内容の危険性判定 Gmail iCloud サブミッション iCloudドメインを問い合わせ iCloudサーバーのIPアドレス リ レ ー 閲覧 フィッシングなど
189. メールフィルタリング • 機械学習などを用いて、「怪しいメールのパターン」を 特定して危険なメールを判断する ◦ かなり昔から研究が進んでいる分野 ◦ 機械学習の分野の先駆け ◦ 「ベイジアンフィルタ」というアルゴリズムが有名 • Gmailなど、大手メールサービスを中心に導入 ◦ Gmailは最近流行りのLLMまで使っている、という 噂がある
190. このように、様々な セキュアにするための 取り組みがある メールサーバーを管理するなら、知っておく必要アリ
191. アジェンダ • なぜ、今メールなのか • プロトコルスタックとRFC • メールが送られる仕組み • SMTPプロトコル • ハンズオン - 「SMTPを手書きしてみよう！」 • SMTPを安全にするための仕組み • ハンズオン - 「メールのソースを見てみよう！」 • メールとの向き合い方
192. アジェンダ • なぜ、今メールなのか • プロトコルスタックとRFC • メールが送られる仕組み • SMTPプロトコル • ハンズオン - 「SMTPを手書きしてみよう！」 • SMTPを安全にするための仕組み • ハンズオン - 「メールのソースを見てみよう！」 • メールとの向き合い方
193. ハンズオン 「メールのソースを見てみよう！」
194. セキュリティプロトコルが 利用されている様子を 実際に見てみよう！ 「生」のメールを見て体感してみよう
195. 別でハンズオン資料を 用意してありますので、 それに従って進めて下さい！ https://github.com/logica0419/ seccamp-mini-ishikawa2025/blob/main/handson-2.md
196. アジェンダ • なぜ、今メールなのか • プロトコルスタックとRFC • メールが送られる仕組み • SMTPプロトコル • ハンズオン - 「SMTPを手書きしてみよう！」 • SMTPを安全にするための仕組み • ハンズオン - 「メールのソースを見てみよう！」 • メールとの向き合い方
197. アジェンダ • なぜ、今メールなのか • プロトコルスタックとRFC • メールが送られる仕組み • SMTPプロトコル • ハンズオン - 「SMTPを手書きしてみよう！」 • SMTPを安全にするための仕組み • ハンズオン - 「メールのソースを見てみよう！」 • メールとの向き合い方
198. メールとの向き合い方
199. なぜここまで様々な 対策が施されているのに、 電子メールは未だ様々な サイバー犯罪に使われるのか？
200. ここからは 事実に基づいた憶測 人間が対策することなので 「正しさ」は保証できない
201. 強固な対策が取りにくい • 対策で、メールを送れなくすることは基本的にない ◦ 正しい送信元か確かめたり、改ざん防止だったり… • プライベートなやり取りであるので難しい ◦ Webページの場合、特定のユーザーにアクセス制限 をかける ▪ 情報の提供者の階層が利用者と別れるため 一元的な指標で不正行為などを定められる ◦ メールでは、「何を不正とするか」が曖昧
202. 共通化の難しさ • Webページのセキュリティは奇跡に近いクオリティ ◦ Chromiumという、Google Chromeの核になる 部分がほぼ全てのブラウザで使われている • 簡単さや社内政治のせいで、メールサービスは乱立 ◦ セキュリティ対策をしなくてもメールは送れて しまうので、セキュリティ対策をしないメール サービスが多い • 何かしらの方法で対策を強要する必要がある
203. Gmailのセキュリティ基準強化
204. Gmailのセキュリティ基準強化 • 「SPF / DKIMを利用していないと、メールを弾く可能 性があるよ」と警告 ◦ 個人メールにおいて圧倒的シェアを持つ影響力 • さくらのメールサーバーをはじめとする、様々なメール サービスが対応を迫られる結果に ◦ 国内のかなり大手のサービスでもまだ仕組みに対応 していないことが判明した • セキュリティ面では、非常に大きな一歩
205. メールから逃れられない人類 • セキュリティを考えれば、メールは排除すべき存在 ◦ ここまで対策しても完全にセキュアとは言えない • ここから20～30年はメールから逃れられないであろう 現状が存在する ◦ 依存するものが多すぎる ◦ 企業間のやり取り、アカウント、etc… • 逃げられないのであれば「まだマシ」な運用をするよう 関わる全員が心掛けなくてはならない
206. アジェンダ • なぜ、今メールなのか • プロトコルスタックとRFC • メールが送られる仕組み • SMTPプロトコル • ハンズオン - 「SMTPを手書きしてみよう！」 • SMTPを安全にするための仕組み • ハンズオン - 「メールのソースを見てみよう！」 • メールとの向き合い方
207. まとめ
208. 今日学んだこと • メールが様々な犯罪に用いられること • RFC (プロトコル) がインターネットを支えていること • メールがSMTPを使って送られていること • SMTPは手書きで書けてしまうほど簡単で、なりすまし が容易にできること • メールを安全にするために様々な取り組みが施されて いること • メールを安全にするのはとても難しいこと
209. メールの仕組みそのものが 脆弱なのは否定できない 「まだマシ」なメールを運用する ために知識を付けよう
210. ありがとう ございました 怪しいメールには 気を付けよう！
211. 参考ページたち • https://www.irasutoya.com/ • https://www.npa.go.jp/hakusyo/r03/honbun/html/xf211000.html • https://sendgrid.kke.co.jp/blog/?p=10300 • 東京工業大学 情報理工学院 情報工学系 講義 「コンピューターネットワーク」 • https://atmarkit.itmedia.co.jp/ait/articles/1411/13/news019.html • https://thinkit.co.jp/story/2015/04/28/5799 • https://www.gmo.jp/security/brandsecurity/dns/blog/dns-server/ • https://wa3.i-3-i.info/ • https://www.tohoho-web.com/ • https://qiita.com/angel_p_57/items/d7ffb9ec13b4dde3357d
212. 参考ページたち • https://ja.wikipedia.org/ • https://www.itmanage.co.jp/column/osi-reference-model/ • https://www.proofpoint.com/jp/threat-reference/dmarc • https://www.naritai.jp/ • https://support.google.com/a/answer/9261504 • https://qiita.com/hirachan/items/d0028da3ebb80b138404 • https://jp.globalsign.com/managed-pki/about_smime.html • https://www.prins.co.jp/knowledge/column/20181101-557/ • https://support.google.com/a/answer/81126 • https://www.sakura.ad.jp/corporate/information/announcements/ 2023/12/19/1968214527/