B2-5 あなたの組織をなりすましから保護するための技術を紹介（TwoFive 桐原氏）

あなたの組織をなりすましから
保護するための技術
株式会社TwoFive
桐原健⼀

なりすましメールの基礎知識

3
Ⓒ 2021 TwoFive,Inc.
典型的なメールのなりすまし⽅法
社員 A
taro@example.jp
取引先 B
MAIL FROM:<taro@example.jp>
From: <taro@example.jp>
EHLO example.jp メールサーバ
（IP アドレス）
エンベロープ
From
ヘッダー
From
SMTP プロトコルでは 3 つの送信者情報をやりとりしている

4
典型的なメールのなりすまし⽅法
社員 A
のなりすまし
取引先 B
EHLO example.jp
エンベロープ
From
ヘッダー
From
しかし、攻撃者は SMTP プロトコルでニセ情報を使うことが簡単にできてしまう
メールサーバ

5
2つのFrom (ヘッダー vs エンベロープ)
ヘッダー情報
◦ メーラーなど画⾯上で確認できる情報
– From: “Taro” <taro@example.com> → ヘッダー From
– To: “Hanako” <hanako@example.com> → ヘッダー To
エンベロープ情報
◦ メールサーバ間の通信(SMTP)で利⽤される情報
– MAIL FROM:<taro@example.com> → エンベロープ From
– RCPT TO:<hanako@example.com> → エンベロープ To
エンベロープ情報
ヘッダー情報
配送に使われる
(メーラーで⾒えない)
メーラーで⾒える

6
ヘッダー情報とエンベロープ情報の組み合わせ例
通常のメール
メルマガ配信ツール(外部サービス)からの配信
ヘッダー From taro@example.com
エンベロープ From taro@example.com
ヘッダー From info@example.com
エンベロープ From 12345-67890-info@bounce.example.com

8
S/MIME (Secure / Multipurpose Internet Mail Extensions)
送信者がメールデータを利⽤して電⼦署名を⾏い、受信者がPKIを使って検証する技術
受信者の証明書を保存していれば、メール⾃体を暗号化して送信できる
◦ 電⼦署名検証: 内容が改ざんされていないか
◦ 証明書の検証: メールアドレスは正しいか、正当な認証局から発⾏された証明書か
証明書
秘密鍵
③
認証局 ① メールアドレス、公開鍵を含む電⼦証明書を発⾏する。
送信者
② メールソフト上に保存した秘密鍵を使ってメールに電⼦署名を付加する。
③ 電⼦署名付きメールを電⼦証明書と共に送信する。
受信者
④ メールソフト上で電⼦証明書を使って電⼦署名、メールアドレスを検証する。
⑤ メールソフト上で電⼦証明書のCAが信頼済みかを確認する。
①
②
証明書
④
社員 A
taro@example.jp 取引先 B
認証局A
認証局A
信頼済み認証局
⑤

9
S/MIMEの現状
なりすまし対策技術の中では、最も歴史が古く、技術的に筋が良いが、現状では普及し
ているとは⾔えない。ただし、PPAP終息に絡んで、課題を解消する動きが活発化。
◦ コスト
– １メールアドレス毎に証明書の購⼊が必要
– 購⼊費⽤だけでなく、申請・購⼊までの⼈的コストも膨⼤
◦ メールソフト
– 携帯メール、webメールサービスなど⾮対応のものが多い
– ⾮対応メールソフトの場合は電⼦署名が「smime.p7s」というファイル名で添付されたり、
本⽂が⾮表⽰になったりする
◦ メーリングリスト
– 件名や本⽂等を書き換えることが多く、電⼦署名が無効になるため、相性が悪い。

11
SPF (Sender Policy Framework)
ドメイン所有者が許可したメールサーバ(IPアドレス)から送信されているか、受信者が確認
する技術。
ネームサーバ
メールサーバ
許可されたメールサーバ
(マーケティングメール、CRM)
許可されていないメールサーバ
第三者のメールサーバ
受信者のメールサーバ
SPF = pass
SPF = fail
SPFレコード確認
v=spf1 +ip:192.168.10.1 +ip:192.168.2.5 -all
SPFレコード
対象のドメイン送信者のエンベロープ From のドメイン
送信者(ドメイン所有者) 許可した IP アドレスリスト(SPFレコード)をネームサーバ(DNS)へ登録する。
受信者 SPF レコードを取得し、メールの送信元 IP アドレスがリストに含まれているか確認する。

13
DKIM (DomainKeys Identified Mail)
送信元メールサーバがメールデータを利⽤して電⼦署名を⾏い、受信者が検証する技術
◦ 電⼦署名検証: 内容が改ざんされていないか
◦ 公開鍵の授受: ドメイン所有者が正しいか
ネームサーバ
メールサーバ受信者のメールサーバ
④
公開鍵
秘密鍵
②
③
⑤
送信者(ドメイン所有者) ① 電⼦署名に使⽤する公開鍵をネームサーバに登録する。
送信者
② メールデータから秘密鍵を使ってメールに電⼦署名を付加する。
③ 電⼦署名付きメールを送信する。
受信者
④ 送信者のドメイン(署名ドメイン)のネームサーバから公開鍵を取得する。
⑤ 公開鍵を使って電⼦署名を検証する。
①

14
送信ドメイン認証技術
ドメイン単位で送信者が名乗っている情報(メールドメイン)が正しいか確認する技術
SPF 規格 DKIM
RFC 7208 ドキュメント RFC 6376 (STD 76)
IPアドレスで判定認証⽅法電⼦署名で判定
エンベロープ From ドメイン保護する対象署名ドメイン
DNS に設定を記述対応の難しさサーバーに実装
Authentication-Results
ヘッダー
確認⽅法
Authentication-Results
ヘッダー
転送に弱い
ヘッダー From 詐称が可能
問題点
メーリングリストに弱い
ヘッダー From 詐称が可能

15
SPF の問題点
社員 A
taro@example.jp
取引先 B
エンベロープ
From
ヘッダー
From
SPF では直前のメールサーバとエンベロープ From の⼀致のみ確認する
詐称が可能

16
DKIM の問題点
社員 A
taro@example.jp
取引先 B
エンベロープ
From
ヘッダー
From
DKIM では電⼦署名の正しさ（署名ドメイン）のみ確認する
秘密鍵
署名ドメイン
詐称が可能

17
SPF と DKIM 共通の問題点
社員 A
taro@example.jp
取引先 B
jiro@twofive25.com
EHLO example.jp
メールの転送によって、SPF 認証が失敗する
個⼈メール
jiro@gmail.com
EHLO twofive25.com メールサーバ
エンベロープ
From
ヘッダー
From
SPF 偽陽性
秘密鍵
署名ドメイン

18
SPF と DKIM 共通の問題点
社員 A
taro@example.jp
取引先 B
メーリングリスト
EHLO example.jp
メーリングリストによって件名などが変更され、DKIM 認証が失敗する
取引先
社員アドレス
MAIL FROM:<ml@twofive25.com>
EHLO twofive25.com
ヘッダー
From
DKIM 偽陽性
秘密鍵
署名ドメイン
メールサーバ
エンベロープ
From

20
DMARC - 2つの機能
IPアドレス(SPF)や
電⼦署名(DKIM)を使って
なりすましメールか
どうかを認証する技術
サーバに届いたメールの
認証結果を
ドメインの管理者に
集計レポートする技術
認証＋集計レポートによって
正しいメールを届けて
なりすましメールを削除する
2017年政府ドメイン義務化
2016年政府サービス義務化
2018年7⽉
サイバーセキュリティ2018記載
2020年6⽉
フィッシングレポート2020記載
認証分析

21
DMARC - 認証（ポリシー機能）
ポリシー機能によるメール取り扱い指定
◦ 認証結果が失敗した場合、受信者にどのように処理してほしいか宣⾔する。
◦ none (何もしない)
– 受信箱へ⼊れる
◦ quarantine (隔離する)
– 迷惑メール判定する、迷惑メールフォルダーへ⼊れる
◦ reject (受信拒否する)
– 送信者へエラーを返す、受信して破棄する

22
DMARC - 分析（レポート機能）
レポート機能によるフィードバック
◦ DMARC/SPF/DKIM認証結果、送信元情報
◦ どのように処理したか
◦ その他

23
DMARC - 動作仕様
レポート機能によるフィードバック
◦ DMARC/SPF/DKIM認証結果、送信元情報
◦ どのように処理したか
◦ その他
SPF、DKIM いずれかで認証 Pass
ヘッダー Fromを保護できる

24
c.f. メール転送
社員 A
taro@example.jp
取引先 B
jiro@twofive25.com
EHLO example.jp
メールの転送によって、SPF 認証が失敗しても DKIM が救済する
個⼈メール
jiro@gmail.com
EHLO twofive25.com メールサーバ
エンベロープ
From
秘密鍵
署名ドメイン
ヘッダー
From

25
c.f. メーリングリスト
社員 A
taro@example.jp
取引先 B
EHLO example.jp
メーリングリストによって件名などが変更され、DMARC認証が失敗する
取引先
社員アドレス
EHLO twofive25.com
ヘッダー
From
DMARC 偽陽性
秘密鍵
署名ドメイン
メールサーバ
エンベロープ
From
DMARC 偽陽性

27
ARC(Authenticated Received Chain)
中間サービス(MLサーバなど)が着信時のDMARC認証結果に電⼦署名を⾏い、受信者
が途中経路のDMARC認証結果を確認・検証する技術
◦ 電⼦署名検証: 保存された途中経路のDMARC認証結果が正しいか
◦ 公開鍵の授受: 中間サービス所有者が正しいか
ネームサーバ
メールサーバ
MLサーバなど
公開鍵
秘密鍵
MLサーバ管理者 ① 電⼦署名に使⽤する公開鍵をネームサーバに登録する。
MLサーバ
② DMARCの認証結果に電⼦署名を付与し、ヘッダに保存する。
③ メールを再送信する。
受信者
④ MLサーバのドメイン(署名ドメイン)のネームサーバから公開鍵を取得する。
⑤ 公開鍵を使って付与されたヘッダの電⼦署名を検証する。
ネームサーバ
公開鍵
①
秘密鍵
受信者のメールサーバ
⑤
②
③
④

28
cf. メーリングリスト
社員 A
taro@example.jp
取引先 B
EHLO example.jp
メーリングリストで、DMARC認証が失敗しても、ARCで救済されることがある。
どの中間サービスを信頼するかについては、受信側の判断に委ねられる。
取引先
社員アドレス
EHLO twofive25.com
ヘッダー
From
秘密鍵
署名ドメイン
メールサーバ
エンベロープ
From
ARC検証

29
ARCで使⽤するヘッダ
ARC では、追加された順番を⽰す番号 (i=) を含んだ3つの新しいメールヘッダが追
加される。
◦ ARC-Seal
– ARC 関連ヘッダを順番ごとに連結したデータから⽣成される電⼦署名
◦ ARC-Message-Signature
– DKIM と同様の再署名情報
◦ ARC-Authentication-Results
– Authentication-Results:ヘッダの保存⽤

31
DMARC メール＆レポートフロー

32
DMARC認証率
調査項⽬結果
SPF成功率 97.15%
DKIM成功率 94.78%
DMARC成功率 94.84%
┗ DMARC SPF成功率 47.14%
┗ DMARC DKIM成功率 88.62%
} SPFとDMARC SPFで成功率の乖離が⼤きい。
◦ エンベロープFromとヘッダFromが異なるアラインメント違反が多い。
◦ 配信事業者などではエラーメールの処理のためにエンベロープFromを配信事業者ドメインに
することが多く、それが影響している。
◦ DMARCに対応している事業者でもデフォルトでは、DMARC仕様としていないことも多い。

34
DMARC - 動作仕様
( SPF が Pass または DKIM が Pass ) かつ "イン・アライメント"
イン・アライメント: ドメイン名が⼀致している
SPF が Pass している場合は・・・
◦ ヘッダー From ドメイン = エンベロープ From ドメイン
DKIM が Pass している場合は・・・
◦ ヘッダー From ドメイン = DKIM 署名ドメイン(DKIM-Signatureのd=タグ)
アライメントモード
◦ strict : ドメイン完全⼀致
◦ relaxed : 組織ドメイン(Organizational Domain)⼀致
– mail.example.co.jp の組織ドメイン(OD) => example.co.jp

35
なりすまし⽅法（例）
ヘッダー From のメールアドレス部分
◦ From: <taro@twofive25.com>
ディスプレイネーム (ヘッダー From のコメント部分)
◦ From: "foo@twofive25.com" <bar@phishing.com>
◦ From: "TwoFive" <bar@phishing.com>
類似ドメイン (cousin/homograph/lookalike domain)
◦ tw0five25.com
◦ twoflve25.com
◦ twofive25.corn
件名
◦ Subject: TwoFiveです
本⽂
◦ お世話になっております。TwoFiveです。

36
DMARC の保護するスコープ
ヘッダー From のメールアドレス部分
◦ From: <taro@twofive25.com>
ディスプレイネーム (ヘッダー From のコメント部分)
◦ From: "foo@twofive25.com" <bar@phishing.com>
◦ From: "TwoFive" <bar@phishing.com>
類似ドメイン (cousin/homograph/lookalike domain)
◦ tw0five25.com
◦ twoflve25.com
◦ twofive25.corn
件名
◦ Subject: TwoFiveです
本⽂
◦ お世話になっております。TwoFiveです。
対象外

37
BIMI の役割
DMARC の認証技術と
詐称メールの隔離・拒否
送信者ブランドロゴ
をメールアプリで表⽰
正当性視認性
ドメインオーナーの
ロゴ画像の所有を証明
所有証明
様々なプラットフォームが WG 参画
DMARC やそのポリシー強化の推進のため
BIMI 規格を策定
参考: https://bimigroup.org/

38
BIMI(Brand Indicators for Message Identification)

39
BIMI = Brand Indicators for Message Identification
ブランドロゴ表⽰には DMARC と p=quarantine 以上が必須
◦ 組織ドメインで p=reject あるいは ( p=quarantine かつ pct=100 )
◦ sp=none の場合は対象外
ブランドロゴ画像を証明する VMC（Verified Mark Certificate）を指定
◦ 認定された認証局によるロゴ画像の所有・商標証明
ブランドロゴ画像（SVG フォーマット）を配置
◦ スクリプトを含まない画像（ SVG Tiny PS ）
◦ HTTPS サーバ上に VMC と合わせてブランドロゴ画像を配置
参考: https://bimigroup.org/
BIMI 対応の前提条件

ご視聴ありがとうございました
フィッシングメール対策は TwoFive におまかせください
https://www.twofive25.com/
info@twofive25.jp

B2-5 あなたの組織をなりすましから保護するための技術を紹介（TwoFive 桐原氏）

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

More from JPAAWG (Japan Anti-Abuse Working Group)

More from JPAAWG (Japan Anti-Abuse Working Group) (20)

B2-5 あなたの組織をなりすましから保護するための技術を紹介（TwoFive 桐原氏）