【18-E-2】Android6.0 対応！モバイルアプリセキュリティの最新トレンド

今日の話題
1.最新Androidアプリの脆弱性事情
2.セキュアなAndroidアプリ開発
• JSSECセキュアコーディングガイドー Android 6.0対応－

会社概要
VAIOのソフト部門が独立してできたソフト専門子会社
ソニーデジタルネットワークアプリケーションズ株式会社
品川区東五反田 2-21-28 (御殿山TEC 13号館）
2000年 8月 1日
1億円ソニー(株)100％出資
ソフトウエアの企画、開発、商品化
262名（2014/4/1現在）
代表取締役中村年範
Copyright 2016 Sony Digital Network Applications, Inc. 3
略称：
SDNA
2016/2/18

最新Androidアプリの
脆弱性事情

突然ですが・・・
Androidアプリは
安全でしょうか？

Androidアプリ
脆弱性調査2015
• 2015年8月18日から9月1日時点で公開されている
• 各カテゴリのダウンロード数上位500位以上、且つ、
1,000ダウンロード以上
• 調査対象アプリ：11,686件
2013年度の調査対象アプリ：6,170件
494
496
427
443
426
474
498
442
426
456
489
498
404381
494
498
489
456
499
499
478
492
459
472
496
カテゴリ別内訳（アプリ総数 11,686)
エンタテイメント
カスタマイズ
コミック
ショッピング
スポーツ
ソーシャルネットワーク
ツール
ニュース＆雑誌
ビジネス
ファイナンス
メディア＆動画
ライフスタイル
ライブラリ＆デモ
医療
音楽＆オーディオ
教育
健康＆フィットネス
交通
仕事効率化
写真
書籍＆文献
通信
天気
旅行＆地域
Androidアプリ脆弱性調査レポート
http://www.sonydna.com/sdna/solution/android_vulnerability_report_201310.pdf
2013年の調査結果は
こちらから↓
2016/2/18

セキュリティ対策：2015年の状況
• 脆弱性リスクのある
アプリの割合
「 93%」
• 2013年と比べて若干の改善
• 一部（先進的な）開発者が
セキュリティに取り組み始めた
と思われる
3ポイント改善
96%→93%
脆弱性リスクのある
アプリの割合
2013年
2015年
2016/2/18

アクセス制御脆弱性リスクは
大きく改善傾向
脆弱性
傾向
29ポイント改善
88%→59%
アクセス制御不備のある
アプリの割合
2013年
2015年
アクセス制御脆弱性リスク
は減少（改善）傾向
アクセス制御不備の脆弱性はその修正
方法が簡単で、効果があるため、多く
の開発組織が取り組んだと思われる
2016/2/18

アクセス制御脆弱性リスクは
減少（改善）傾向
27%
アクセス制御
不備
3107件
79%
アクセス制御
不備
5560件
38%
アクセス制御
不備
755件
29%
アクセス制御
不備
1992件
Activity Broadcast Receiver Content Provider Service
85%
アクセス制御
不備
5171件
89%
アクセス制御
不備
3005件
64%
アクセス制御
不備
484件
93%
アクセス制御
不備
3217件
Activity Broadcast Receiver Content Provider Service
2013年データ
2015年データ
脆弱性
傾向
2016/2/18

アクセス制御不備の脆弱性事例
勝手にツイートされて
しまうTwitterアプリ
2016/2/18

勝手にツイートされてしまう
Twitterアプリ
【問題】
ユーザーが知らないうちに、端
末の中のプライベートな写真が
勝手にTwitterにアップロードさ
れてしまう問題があった
つまりプライベートな情報の漏
えいが発生
Twitter
アプリ
悪い
アプリこの画像でTweetして！
お願い♪
オッケー！
ユーザ視点：
「勝手に写真をアップ
ロードするとんでもない
Twitterアプリだ！！」
2016/2/18

勝手にツイートされてしまう
Twitterアプリ
【原因】
画像アップロード用の部品が他
のアプリから（意図せず）アク
セス可能な状態となっていた
つまり他のアプリから画像アッ
プロード機能を勝手に利用する
ことができてしまった
画像Upload用
Activity
悪い
アプリ
アクセス可能！！
2016/2/18

HTTPS通信利用は増加傾向
インターネット通信機能を
持つアプリの内、88%の
アプリがHTTPSを使って
通信する
昨今のWeb事情を反映している
と思われます
16ポイント改善
72%→88%
暗号通信する
アプリの割合2013年
2015年
2016/2/18

HTTPS通信利用は増加傾向
• 昨今のWebの事情を反映していると思われる（例）
https://twittercommunity.com/t/restricting-api-twitter-com-to-ssl-tls-traffic/12331
http://googlewebmastercentral-ja.blogspot.jp/2014/08/https-as-ranking-signal.html
2016/2/18

（一方）HTTPS実装の脆弱性
HTTPS実装の脆弱性リス
クのあるアプリの割合は、
やや増加傾向
安易なHTTPS実装は、
安全な実装に寄与しない
可能性がある点に注意
脆弱性
傾向
4ポイント悪化
39%→43%
暗号通信が解読・改ざん
されるリスクのある
アプリの割合
2013年
2015年
2016/2/18

HTTPS実装の脆弱性事例
通信内容を
盗み見られてしまう
ECサイトアプリ
2016/2/18

通信内容を盗み見られてしまう
EC
アプリ
悪い人
【問題】
ECサイトとのやり取りを盗み見
られてしまう問題があった
攻撃者はログインIDやパスワード、
クレジットカードの番号などを入
手できた
HTTPS
ECサイト
2016/2/18

通信内容を盗み見られてしまう
EC
アプリ
【原因】（Man In The Middle Atack/中間者攻撃）
サーバ証明書の検証でエラーが発生しているにもかかわらず、エ
ラーを無視して通信を続けたため通信を盗聴されてしまった
エラー
無視！！
ユーザ視点：
「そんなチェックも
していなかったの？
信用できない！！」
全ての通信が攻撃者のPC経由になるよう
仕掛けをしたWiFiアクセスポイント
ECサイト
攻撃者のPC
2016/2/18

その他の傾向
2016/2/18

強度の弱い暗号技術が
利用されている割合は高い
• MD5、DESなど強度の
弱い暗号技術が利用され
ている
CRYPTREC
電子政府推奨暗号リスト
http://www.cryptrec.go.jp/images/cryptrec_ciphers_list_2013.pdf
62%
脆弱な暗号技術を利用
するアプリの割合
2016/2/18
脆弱性
傾向

既に非推奨となっている機能を
使っているアプリが残っている
http://developer.android.com/intl/ja/reference/android/content/Context.html
API Level 17で非推奨となった
MODE_WORLD_READABLE / MODE_WORLD_WRITEABLE
22%
MODE_WORLD_Xを
利用するアプリの割合
脆弱性
傾向
2016/2/18

ダウンロード数別
脆弱性リスク傾向
アプリの脆弱性対策が本格的に始まっている
一方で、正しいセキュアコーディングの普及・啓発が不十分
脆弱性
傾向
0%
20%
40%
60%
80%
100%
10億～
5億～
1億～
5000万～
1000万～
500万～
100万～
50万～
10万～
5万～
1万～
5000～
1000～
脆弱な暗号通信実装
addJavascriptInterface
脆弱な暗号技術の利用
MODE_WORLD_Xの利用
アプリのダウンロード数
脆弱性リスクを含むアプリの割合
2016/2/18

総務省推奨基準となっている
Androidセキュリティの教科書
知っていれば防げたというノウハウで構成されている。
Androidアプリセキュリティのノウハウ集
通称：JSSECセキュアコーディングガイド
PDF文書とセキュアなサンプルコード一式（無償）
http://www.jssec.org/report/securecoding.html
「Android セキュアコーディング」と検索
デファクトスタンダードなガイド・基準
総務省も推奨のガイド。
通信キャリアや
多くのアプリベンダーでも活用。
受入基準にするアプリ発注会社もある。
http://www.soumu.go.jp/menu_news/s-news/
01ryutsu03_02000043.html
Copyright 2016 Sony Digital Network Applications, Inc. 242016/2/18

ガイドの歴史
年1回から2回のペースで改訂
2014年、英語版リリース
2012年6月 2012年11月 2013年4月 2014年7月
2014年4月 2014年8月
2016/2/18
2015年6月

最新第6版 2月3日公開
26
• Android 6.0対応
– Permissionモデルの変更に対応
• permission の protectionLevel 変更
– ネットワーク系のpermissionは軒並みnormalへ！？
• 新しいPermission Model
– アプリ実行中に必要なタイミングでユーザー許諾を得る
– 指紋認証を使ったアプリ
• Android Lまでの新規項目追加
– Lollipopで刷新された Notification まわり
– getRunningAppProcess()仕様変更
– WebViewに追加された最新機能の注意点
Copyright 2016 Sony Digital Network Applications, Inc.2016/2/18

以下の項目をご紹介します
1. 新しいPermissionモデル
(Runtime Permission)
2. 指紋認証によるユーザー認証
3. Notification Visibility

新しい Permission Model
従来のPermission確認画面新しいPermission確認画面
インストール
時に確認
実行時に確認

新しい Permission Model
• 保護レベルがdangerousのpermissionのみ
影響
① 実行中の必要に応じたユーザー許諾
② Permission Group単位での権限管理
同じPermission Groupに属するpermissionは
一度の要求で全てgrantされる
③ ユーザーによる許可の取り消し (revoke)
– targetSdkがAndroid Mより前のバージョンでも、
Android M 端末上では、ユーザーは権限をrevokeできる
– Android Mより前のOSの動作する端末上では
新しいモデルは適用されない

権限要求用のAPIを呼び出す
• 以下のメソッドで権限を要求する
– Activity.requestPermissions(String[], int)
– Fragment.requestPermissions(String[], int)
• 第一引数で必要なpermissionを列挙
• 第二引数でコールバックに渡すリクエストコードを指定
– startActivityForResult →onActivityResult とよく似ています
// READ_CONTACTSを要求する例
requestPermissions(
new String[] {Manifest.permission.READ_CONTACTS},
REQUEST_CODE);
こんな感じのダイアログが出ま
す。レイアウトは変更できません

結果をコールバックで受け取る
• 権限要求用APIを呼び出した
Activity/Fragment
のコールバックで結果を受け取れます
– Activity.onRequestPermissionsResult
– Fragment.onRequestPermissionsResult
• 引数にそれぞれ、リクエストコード、要求した権限(String配列)、結果
(Granted/Denied)が渡される
// READ_CONTACTSの例
public void
onRequestPermissionsResult(int reqCode,
String[] permissions, int[] results) {
// 結果をみて、処理を進める
}
ユーザーの選択後に呼び出される。
「許可」した場合、
permissions = [READ_CONTACTS],
results = [PERMISSION_GRANTED]
となる。

(最低限度)
Android 6.0に対応するために
• Android Mの端末上で動作する (落ちない)
アプリにするために、最低限下記の対応が
必要となります
• dangerousレベルのpermissionが必要な
アプリは
– Activity, Fragmentで
• requestPermissionsを呼び出し
• onRequestPermissionsResultをオーバーライドする
– Service, Providerなどで
権限の必要なAPIを呼び出す場合
• Context.checkSelfPermissionで権限が付与されているか
確認してからAPIを呼ぶ
– Providerの場合はgetContext().checkSelfPermission(…)

指紋認証(Fingerprint)
Copyright 2016 Sony Digital Network Applications, Inc.
• Android 6.0 (API Level 23)以降
• 22以前との互換性は、FingerprintManagerCompatクラスを
使用することで吸収可能
• Fingerprint機能が端末にないと使用不可
• FingerprintManager.isHardwareDetected()
• ロックが設定されていないと使用不可
• KeyguardManager.isKeyguardSecure()
• Fingerprintが登録(Enroll)できない
• 指紋が登録されていないと使用不可
• FingerprintManager.hasEnrolledFingerprints ()
2016/2/18 35

アプリが指紋認証を使う目的
アプリが端末ユーザーを
「簡易的に」認証するため
• 端末ユーザーのみ実行可能な
機能を保護したい
• 機能実行時の認証
• 端末ユーザーのみ実行可能な
機能の操作を簡略化したい
• 機能実行時の認証の簡略化
• 例：楽天銀行アプリがログインに使用
2016/2/18 36

指紋認証の特徴
ID/Passwordに比べて
[良い点]
• 入力が容易(覚える必要もない)
• 端末へのアクセスが必要（攻撃を受けにくい）
[悪い点]
• 認証としての強度は弱い（ところもある）
– 秘匿困難性、人工物による認証、認証精度
• 指紋が漏れてても変えられない
– 非交換性
• 生体変化や環境条件による識別精度の低下
– パスワードのように一意に決まらない
– ケガなどで認証ができなくなる可能性

Fingerprint Architecture
App
SystemServer
IFingerprintService
FingerprintService
fingerprintd
IFingerprintDaemon
FingerprintDaemonProxy
Fingerprint
Sensor
Fingerprint
HAL
Kernel
and/or
TEE
FingerprintManager
DeviceUser
Templates
Kernel/TEE
Implementations
are different
according to makers
and operators.
authenticate
enroll
etc…
android.permission.USE_FINGERPRINT (normal) is needed to authenticate
android.permission.MANAGE_FINGERPRINT (signature) is needed to enroll/remove
keystore
addAuthToken if verified.
最終的には
暗号鍵と連携
して動作

（参考）AndroidKeyStore
• 機能
– 鍵の管理(KeyStore)：
Import/Export (Store/Load)
– 鍵の生成(KeyGenerator)
– 鍵の使用(Cipher/Signature/Mac)：
暗号化・復号、署名・検証
• 指紋認証との関係
– 上記で暗号鍵を生成 or 既存の鍵を登録するとき
– 生成 or 登録以後に鍵を使うに際の条件として
– 指紋認証（で認証すること）を条件に設定できる

アプリが指紋認証を使うときは…
• 指紋認証の弱い点を考慮する
– 指紋認証だけに頼る設計にはしない
• 認証ができなくなった（生体が変化するなど）でも、
別手段で機能を利用できるようにする
– 機密性の高い情報・機能は（直接）扱わない
• 課金や決済といった重要な情報・機能を扱う際は
かならず他の認証方法と併用する
• 正しい暗号の使い方も理解する
– 指紋認証は暗号処理と密接に関連するため、
正しい暗号の使い方も理解しておく必要がある
• アルゴリズム選択、鍵長の設定、端末内での鍵管理方法、暗号機能
自体の認証・・・

今どきのNotification（通知）
画面ロック中にもNotification（通知）表示
2016/2/18 42
画面ロック中
Notificationが
表示
メール着信などが分かり
利便性が上がりました

Notification Visibility
Notificationを表示する条件設定
2016/2/18 43
Visibilityの値 Notificationの振る舞い
Public すべてのロック画面上でNotificationが表示される
Private
すべてのロック画面上でNotifcationが表示されるが、
パスワード等で保護されたロック画面（セキュア
ロック）上では、Notificationのタイトルやテキス
ト等が隠される（プライベート情報が隠された公開
可能な文に置き換わる）
Secret
パスワード等で保護されたロック画面（セキュア
ロック）上では、Notificationが表示されなくなる
（セキュアロック以外のロック画面では
Notificationは表示される）
※ Android 6.0 現在のVisibilityのデフォルト値は「Private」

Notification Visibility
パスワード等で保護されたロック画面
（セキュアロック）
保護のないロック画面
（アンセキュアロック）
ロック解除後の画面
（通常画面
Public Notification
Secret
Notification

Notificationのセキュリティ
セキュアロックで表示
するNotificationに、
ユーザーのプライバ
シー情報が含まれてい
ると・・・
画面ロック解除できなくても
端末に近寄れる人（拾った人等）に
プライバシー情報が見られてしまう
Notificationが画面ロック中にも
表示されるようになったことで
新たなセキュリティ問題が発生する
可能性が生まれた
個人情報漏えい

Notificationの注意点
• Visibilityと通知内容
– 表示しようとしている情報は設定したVisibilityに
沿った内容であるか確認
– デフォルト値に頼らず明示的にVisibilityを設定
• Private Notificationの使い方
– Private Notificationは内部にPublic Versionを保持
– 画面ロック中にユーザーに見せる情報と、ロック解
除後に見せる情報を正しく切り分け・設定すること
• 例：メール情報
画面ロック中：メール通知があったことのみを通知
ロック解除後：メールの本文や送信者などの情報を通知（可能）

まとめ
1. Androidアプリの脆弱性問題
Androidアプリのセキュリティ事情
2. セキュアなAndroidアプリ開発法
• JSSECセキュアコーディングガイドー Android 6.0対応－

“Sony”はソニー株式会社の商標です。
各ソニー製品の商品名・サービス名はソニー株式会社またはグループ各社の登録商標です。その他の製品および会社名は、各社の商号、登録商標または商標です。
ソニーデジタルネットワークアプリケーションズ株式会社
〒141-0022 東京都品川区東五反田 2-21-28 （御殿山 13号館）
(代表) 050-3750-1897

【18-E-2】Android6.0 対応！モバイルアプリセキュリティの最新トレンド

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (9)

Destacado

Destacado (20)

Similar a 【18-E-2】Android6.0 対応！モバイルアプリセキュリティの最新トレンド

Similar a 【18-E-2】Android6.0 対応！モバイルアプリセキュリティの最新トレンド (20)

Más de Developers Summit

Más de Developers Summit (20)

Último

Último (11)