ゲーム開発を加速させるクライアントセキュリティ

Copyright © DeNA Co.,Ltd. All Rights Reserved.
ゲーム開発を加速させる
クライアントセキュリティ
May 17, 2017
Tetsuya Shiota
Cyber Security Dept.
DeNA Co., Ltd.
LINE and Intertrust Security Summit

⾃⼰紹介
!  Tetsuya Shiota (汐⽥徹也) @shioshiota
⁃  セキュリティエンジニア@DeNA
•  新卒⼊社からずっとセキュリティ技術グループ
⁃  学⽣の頃: プログラミング⾔語の研究・競技プログラミング
!  ミッション:
⁃  すべてのサービスの脆弱性診断
•  スマホゲーム・ゲームプラットフォーム・ECサイト等
⁃  設計のセキュリティ⾯のレビュー
•  認証認可フロー・購⼊フロー・チート対策設計等
⁃  インシデント対応
⁃  社内セキュリティの改善・監視
2

DeNAの事業領域について
!  オンラインモバイルゲーム
!  ゲームプラットフォーム
⁃  PC, モバイル
!  ECサイト
⁃  旅⾏, オークション
!  エンタメ系モバイルサービス
⁃  電⼦書籍、ライブ配信サービス
!  オートモーティブ
⁃  カーシェアリング
!  コミュニティサービス
!  ヘルスケア
!  スポーツ事業 3

DeNAの事業領域について
!  オンラインモバイルゲーム
!  ゲームプラットフォーム
⁃  PC, モバイル
!  ECサイト
⁃  旅⾏, オークション
!  エンタメ系モバイルサービス
⁃  電⼦書籍、ライブ配信サービス
!  オートモーティブ
⁃  カーシェアリング
!  コミュニティサービス
!  ヘルスケア
!  スポーツ事業 4
今⽇の話

セキュリティが開発速度を加速させる？
!  セキュリティに対する⼀般的なイメージ
⁃  開発速度を下げる
⁃  コストがかかる（⼯数・製品などの費⽤）
⁃  評価しにくい
•  特にクライアントセキュリティは顕著
•  どこまでやるべきか
!  クライアントセキュリティで開発速度を加速できる！と
いう考え⽅
⁃  今⽇の話
5

今⽇の話
1.  モバイルゲーム開発アーキテクチャとセキュリティ
⁃  ゲーム開発アーキテクチャの紹介
⁃  クライアントセキュリティによって可能になること
⁃  セキュリティはゲーム開発を加速できる
2.  モバイルゲームのチートリスクとその対策
⁃  サーバで防げるチート・防げないチート
⁃  デモ: クライアントセキュリティが弱い場合の攻撃例
⁃  セキュリティレベルの考え⽅
⁃  セキュリティソリューションを導⼊するための課題
3.  まとめ
6


モバイルゲーム開発
アーキテクチャとセキュリティ
セキュリティは開発速度を加速させるのか
7

ゲームのクライアントセキュリティは何を守る？
8
攻撃者が最終的に実現したいことは……
↓
サーバ上のデータを不正なものにしたい
=> 我々はこれを防⽌したい！
不正なプレイデータの保存を
防⽌することが重要
改ざんしたスコア
不正なクライアントで
有利に進めたスコア
Hack!!

3種類のモバイルゲーム開発アーキテクチャ
!  ブラウザ型
⁃  ほぼすべてのロジックはWebサーバ内に存在
⁃  クライアントが持つロジックは演出がメイン
!  アプリ型
⁃  ゲームごとに専⽤のサーバとクライアントアプリを開発
⁃  インタラクティブなUXが必要な場⾯ではクライアント側にロ
ジックを持つ
!  BaaS利⽤アプリ型
⁃  多数のゲームで、単⼀のゲームサーバを共⽤して使う
⁃  クライアントが持つロジックの割合が⾼い
⁃  クライアントアプリは、それぞれ別で開発
9

ブラウザ型
!  基本的にはサーバサイドのみを開発
!  ほぼすべてのロジックはサーバ側に存在
!  クライアントが持つロジックは演出メイン
10
サーバ側のデータで
ダメージ計算攻撃！
ボタンを押したよ！
敵の体⼒が減ったよ！
敵の体⼒ –= ユーザの攻撃⼒

アプリ型
!  サーバサイドもクライアントサイドも開発
!  ⼀部の重要なゲームロジックがクライアント側に存在
⁃  ユーザ操作によって変動するスコア計算等
11
クライアントから送られたスコア値と
サーバ側のロジックで、
プレイヤーデータを更新
スコア100でクリア！
スコアに基づいて、
レベルを更新したよ！
スコアに基づいて
プレイヤーを成⻑
ゲームクリア！
ユーザの操作に応じて
スコアを計算

BaaS利⽤アプリ型
!  基本的にはクライアントサイドのみの開発
⁃  共通のゲームロジックを実装した単⼀の共通サーバを利⽤
!  クライアントが持つゲームロジックの割合が⾼い
12
ゲームA ゲームB ゲームC

BaaS利⽤アプリ型
!  基本的にはクライアントサイドのみの開発
⁃  共通のゲームロジックを実装した単⼀の共通サーバを利⽤
!  クライアントが持つゲームロジックの割合が⾼い
13
ある程度クライアントからのデータを
信じてプレイデータを更新
スコア100で
ステージAをクリアしたよ！
保存したよ！
保存！
ユーザの操作に応じて
ゲームロジックを計算

アーキテクチャによるチート耐性の違い
ブラウザ型アプリ型 BaaS利⽤型
UX △ ◎ ◎
開発コスト ◎ △ ◯
チート耐性 ◎ ◯ △
14
!  プロジェクトによっては、採⽤するアーキテクチャは
様々
!  クライアントが持つロジックの割合に応じて、チート耐
性が変化する

アーキテクチャによるチート耐性の違い
ブラウザ型アプリ型 BaaS利⽤型
UX △ ◎ ◎
開発コスト ◎ △ ◯
チート耐性 ◎ ◯ △
15
!  プロジェクトによっては、採⽤するアーキテクチャは
様々
!  クライアントが持つロジックの割合に応じて、チート耐
性が変化する
特にクライアントセキュリティで
改ざん・解析から守る必要あり

チートとクライアントセキュリティ
16
!  チートの数を減らすために、クライアントセキュリティ
の技術が必要！
⁃  クライアントにゲームロジックを持つことがあるため
⁃  クライアントセキュリティを⾼める（事前対策）ことで、
チートの発⽣数を減らすことができる
⁃  アプリ改ざん、メモリ改ざん、通信改ざん等チート⼿法へ
の対策・監視
!  チートの数を減らしたい！
⁃  数が多いと、事後対応(監視・BAN)の⼯数が多くかかる
⁃  対応まで時間がかかると、通常のユーザのUX劣化にも繋が
る
•  ゲームバランスの崩壊、PvPでの被害、不公平感

クライアントセキュリティは開発速度を加速させるのか
!  開発速度を加速できると考えている
⁃  アーキテクチャの選択肢が広がり、よりチームにあった開発
が可能になる
⁃  より監視・チート事後対応の⼯数を削減できるため
•  チート発⽣件数の削減
!  クライアントが持つロジックの割合が⾼いゲームほど、
⾼いクライアントセキュリティが求められる
17

モバイルゲームの
チートリスクとその対策
チート対策の考え⽅
18

セキュリティチームとゲーム開発者の関わり⽅
19
!  セキュリティ技術グループ
⁃  ⼈数は10⼈弱
⁃  DeNAから出るほぼ全サービスを脆弱性診断
•  新規アプリで3⽇から2週間程度
⁃  脆弱性診断内製によるメリット
•  スケジュールの柔軟性、社内フレームワークを理解した
診断が可能
設計開発検証リリース
設計のレビュー脆弱性診断
相談対応・レビュー

脆弱性診断で何を指摘するか
!  脆弱性（対応する）
⁃  情報漏えい等に伝わるもの、他者に迷惑のかかる攻撃が可能
なもの
•  SQLインジェクション、権限管理、認証認可まわり等⼀般的なも
の
•  通信の暗号化漏れ
⁃  サーバ側で防げるチート
•  サーバサイドでのゲームロジック確認漏れ・トランザクション管
理不備
!  チートの予防（個別判断）
⁃  root化検知・アプリ改ざん検知・通信改ざん検知
•  いたちごっこになりえるチート対策
20

脆弱性診断で何を指摘するか
!  脆弱性（対応する）
⁃  情報漏えい等に伝わるもの、他者に迷惑のかかる攻撃が可能
なもの
•  SQLインジェクション、権限管理、認証認可まわり等⼀般的なも
の
•  暗号化漏れ
⁃  サーバで防げるチート
•  サーバサイドでのゲームロジック確認漏れ・トランザクション管
理不備
!  チートの予防（個別判断）
⁃  root化検知・アプリ改ざん検知・通信改ざん検知
•  いたちごっこになりえるチート対策
21
そのゲームで最悪どんなチートができるか
ゲーム性として・ビジネスとして致命的か
攻撃の難易度・監視状況等
タイトルの⽅針を踏まえて総合的に判断

サーバサイドにロジックがあると防げるチート
!  ゲームロジックをサーバでちゃんと検証したら防げるチ
ートは対応する
⁃  バリデーションの不備
⁃  トランザクション管理不備等
22

サーバにロジックがあると防げるチート
23
お⾦を減らすよ！アイテム購⼊！
10個購⼊
購⼊できました
10コイン × 10個 = 100
残⾼:1000 – 100 = 900

サーバにロジックがあると防げるチート
24
残⾼を減らすつもりが
増えたよ！
アイテムの個数
を改ざん！
マイナス100個購⼊
購⼊できました
10コイン × -100個 = -1000
残⾼:1000 + 1000 = 2000改ざんされた！

クライアントにロジックがあり防げないチート
!  例: ゲームプレイ結果のスコアを改ざん
⁃  通信を伴わないユーザ体験を提供したい場合
⁃  改ざんしたのか、上⼿にプレイしただけなのか、区別できな
い
25
スコア100でクリア！
スコアに基づいて、
レベルを更新したよ！
ここが改ざんできる！ユーザの操作をもと
にスコアを計算

デモ - クライアントセキュリティが⽢い例
26
⽬標: Proxyツールを利⽤した通信改ざんを⾏う
リクエスト
悪い事をする⼈の環境
改ざん
改ざんされた
リクエスト
Proxy
ツール
!  社内で⽤いる、研修⽤のサンプルアプリです。
!  簡単な通信改ざん対策を突破してみよう！
⁃  研修⽤なので弱く作られています。

!  送信されるリクエストの例
27
POST /sfx/get_user_info.php HTTP/1.1
Accept-Encoding: identity
User-Agent: Dalvik/1.6.0 (Linux; U; Android 4.1.2; sdk Build/
MASTER)
Host: appdemo.example.com
Connection: Keep-Alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 80

WgMBAQ1RU1FLX1BHRwpEUlJIGwY2Gg1RQk0RDlIaERIRFEMKXUpcQB1aRFsHTx
kUGBNFUV5EXUtJDFAW
Base64っぽいけど
デコードしても謎⽂字列

!  バイナリ解析の様⼦（リクエスト暗号化？の鍵を探す）
28
解析対策をしていないと、
簡単・⼀般的なロジックの場合、
⼀瞬で復号するプログラムを
作成されてしまう場合がある
1. ｢Base64｣で検索
2.ロジックをちょっと追って
鍵っぽい⽂字列を探す

29
リクエストを復元し、難読化した対策を突破する
③平⽂を
⼿動で改ざん
⑤改ざんされた
リクエスト
Proxyツール
復元・再難読化
モジュール
Intercept
①
②復元
④
悪い事をする⼈の環境

「チートはできる」ので、「されにくく」する
!  攻撃者はどう狙ってくる？
⁃  通信改ざん・再送
⁃  メモリ改ざん
⁃  アプリ改ざん
!  されにくさは重要であると認識していることが⼤切
!  「されにくく」って？
⁃  攻撃の前提を上げていくことがチート対策
⁃  攻撃者の技術レベルを仮定して評価する
•  通信改ざんだけできる？暗号解くモジュール作れる？
•  メモリ改ざんだけできる？値の検索だけ？変化量も⾒れる？
•  アプリの改ざんもできる？
•  バイナリも読める？C#やJavaだけ読める？
⁃  攻撃の他者への提供容易性も考慮に⼊れる
30

「チートはできる」ので、「されにくく」する
!  攻撃者はどう狙ってくる？
⁃  通信改ざん・再送
⁃  メモリ改ざん
⁃  アプリ改ざん
!  されにくさは重要であると認識していることが⼤切
!  「されにくく」って？
⁃  攻撃の前提を上げていくことがチート対策
⁃  攻撃者の技術レベルを仮定して評価する
•  通信改ざんだけできる？暗号解くモジュール作れる？
•  メモリ改ざんだけできる？値の検索だけ？変化量も⾒れる？
•  アプリの改ざんもできる？
•  バイナリも読める？C#やJavaだけ読める？
⁃  攻撃の他者への提供容易性も考慮に⼊れる
31
⼤切なのは
できるかできないか、
だけではない！

例: デモアプリのセキュリティレベル
!  単純な通信改ざんを防ぐことができているか
⁃  YES
⁃  通信内容が難読化されているため、単にプロキシするだけで
は、攻撃できない
!  チートにアプリ改ざんが必要か？
⁃  NO
⁃  公開鍵を限定した暗号等ではないので、アプリ改ざんなしで
中間者攻撃が可能
!  チートに動的解析が必要か？
⁃  NO
⁃  静的にバイナリ内に埋まっている
⁃  シンボル情報も残っており、⾮常に簡単
32

対策攻撃
複合的に対策を導⼊することで効果を⾼める
!  対策とその依存関係
33
メモリ改ざんメモリ改ざん検知
通信改ざん
アプリ改ざん
Pinning等公開鍵暗号
アプリ改ざん検知
Root化検知
防⽌強化
難読化ツール
全体を強化できる

セキュリティソリューション製品の導⼊障壁
!  導⼊できることが理想的だが、難しい場合も多い
⁃  開発してから後から適⽤するのが難しい
⁃  iOSとAndroidのセキュリティレベルに差がある
⁃  起動時間の⻑時間化(ゲームによっては致命的)
⁃  ビルド時間の⻑時間化
•  ゲームのリリースサイクルでは現実的でないことも・・・（⽉
2回とか）
⁃  その他、ツール起因のバグも発⽣しうる
!  開発者⾃⾝で評価することが難しい
⁃  改ざん検知機能があるが、実際に重要な関数を改ざんして
も検知されないことも
⁃  評価するセキュリティエンジニアが必要
34

まとめ
!  クライアントセキュリティはゲーム開発を加速できる
⁃  アーキテクチャの選択肢が広がり、よりチームにあった開発
が可能になる
⁃  より監視・チート事後対応の⼯数を削減できる
•  チート数の削減
!  「チートはできる」ので、「されにくく」する
⁃  されにくさは重要があると認識していることが⼤切
⁃  攻撃可能な攻撃者のレベルで、「されにくさ」を判断する
!  セキュリティソリューション製品の導⼊が難しい場合も
多い
⁃  安定性・開発⼯数・検証⼯数の増⼤・・・
35

ゲーム開発を加速させるクライアントセキュリティ

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (11)

Similaire à ゲーム開発を加速させるクライアントセキュリティ

Similaire à ゲーム開発を加速させるクライアントセキュリティ (20)

Plus de LINE Corporation

Plus de LINE Corporation (20)

Dernier

Dernier (9)