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

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

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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (11)

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

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

More from LINE Corporation

More from LINE Corporation (20)

Recently uploaded

Recently uploaded (10)