明日、敗訴しないためのAndroidセキュアコーディング・フォローアップ

  • 45
    いいね
  • 1
    コメント
この記事は最終更新日から1年以上が経過しています。

本日(2016/02/18)、DroidKaigi 2016で「明日、敗訴しないためのAndroidセキュアコーディング」をお話させていただきました。終わった際にいくつか質疑応答を頂いたので振り返ったのですが、私が質問の意図を完全に把握出来ず変な回答をしている気がしたので、発表の緊張から解放された今、改めて自分の考えを記載しようと思いました。

資料はこちら

質問1: パスコードを暗号化してファイルにぶっこんでも、引張だしたら解析されてしまうのでは?

  • これに対する回答はYesです。共通鍵だろうと公開鍵だろうと、それをアプリ上で作る以上、複合は余裕です。正直、アプリ上で作る以上その呪縛からは逃れられない(回答時に言えなかったこと)
  • ただ私が作っているアプリ上で、暗号化しているものはパスコードのみです。ぶっこ抜いたパスコードは遠隔からでは使えない様にしているため、遠隔からの攻撃についてはセーフ。物理的に入手した端末から更にパスコードを抜くのは、そもそもそこまでするモチベーションが攻撃者にとってのコストメリットがないと考えているため、そのリスクは許容しています(回答時に言おうとしてたかったこと)
  • ただ上記は私が製作しているアプリでは,,,という話です。設計なのでアプリによってその辺の考えはケース・バイ・ケースになります(本当に言いたかったこと)
  • その後に教えて頂きましたが、keyStoreを使った方法があるみたいですね。release build時のみに発動するようにすれば、それが普遍的に使える手段になり得るかもしれないです。

質問2: 標準的なガイドに従う以外の方法はとっているのか

  • 第三社にセキュリティ診断を定期的に依頼している(回答した答え)
  • 常に攻撃者の視点を持って開発をしています。攻撃者はアプリのどの資産をどのように入手したいのか。その入手可能な資産は、入手仮定のコストに見合っているのか、等々を考えながら、設計しています(本当に言いたかったこと)
  • そもそもJSSECのセキュアコーディングガイドは標準ではないです(別の聴講者様のフォロー)
    • IPAは経済産業省所管の独立行政法人となります。なので、裁判所も根拠として利用しやすかったのかと思われます。一方JSSECは企業の人間が集まった一般社団法人です。なので、そのセキュアコーディングガイドがデファクトにはまだなってないと思います(更にフォロー)

最後に

  • 本日はお忙しい中、私の発表を聞いていただきまして誠にありがとうございました。もし何かご指摘があれば是非お願い致します。よりセキュアなサービスを出して、別の方向からも付加価値をつけていきたいと思います。

KeyStore Provide使ってみた

これを参考にやってみました。が、結局root権限を取得できた端末からだと、下記の通りKeyStore Providerで作られた秘密鍵をぶっこ抜けてしまうので、ぶっこ抜き&解読問題の解決は難しそうです。

root@vbox86p:/data/misc/keystore/user_0 # ls -l                                
-rw------- keystore keystore      788 2016-02-21 13:15 10091_USRCERT_hogehoge
-rw------- keystore keystore     1252 2016-02-21 13:15 10091_USRPKEY_hogehoge <-------秘密鍵

build.gradleで指定したsignInConfigで出来ないか試してみましたが、そもそもsignInConfigを参照をできない(私が試した限りでは)。

なので、ぶっこ抜き問題に関する解決方法あったら教えて頂けるとありがたいです(涙