DroidKaigi2017の振返り「ドキッ★脆弱性 onCreate() から onDestroy() まで」#droidkaigi #android
DroidKaigi2017に登壇・運営スタッフ参加したので、その振返りです。
ドキッ★脆弱性 onCreate() から onDestroy() まで
スピーカーとしての振返り
8000円の参加費をとる平日開催のカンファレンスなので気合いれてたつもりだ。 まずやったことは、OverViewの作成だ。1月頭にグワ〜っと各章のタイトルと順番をつけていった。この時点で講演時間は考慮していない。
次に、各章の締め切りとアウトプットする場を設けていった。具体的にいうと毎月開催されるPotatotipsなどの勉強会でLTをすることで、各章を完遂させた。例えば1月には、当時の体制や対応のタイムラインについてPotatotipsで話した。2月には脆弱性が生まれた原因を潰すカスタムリントを作って、やはりPotatotipsでLTした。同月には、セキュリティの勉強会で脆弱性の原因についてLTした。
最後に、各章の整理だ。これは、リハーサルと同時並行で実施した。実際に声煮出すことで、聴講向けのスムーズな構成にするだけでなく、内容を記憶できたため、資料をスリム化させることができた。
本番だが、練習のお陰で、言葉につまることは少なかったと思う。資料に目を向けることを最小限にしつつ、リスナーとうまい具合にコミュニケーションを取れたと思う。ただ、滑舌に改善の余地はあるので、気長に取り組んでいきたい。尚、練習時は25分の長さだったが、本番時は20分まで短縮できた。
誤算としては、30分が意外に短く、かなり内容を削らなければならなかったこと。50分にしておけば実際の攻撃デモや体制を紹介できたのではないだろうか。また、折角の共有なのだから、英語でチャレンジするのも良かったのではないだろうか…後はおまけスライドにミスがあったことかな…
余談ですが、筋肉の前説をいれたのは(自分の)緊張をホグすためでした。
運営としての振返り
事前準備に関しては、基本的に箱詰めをお手伝いしたり、請求書を集めたりなどの簡単な作業をお手伝いしてた。会場の支払い、CONBUさんとの交渉、タスク管理、受付のプラン、公式アプリを作るなどなどと比べてライトな作業だったと思います。そういったことを本業と並行してするのはスゴイの一言に尽きますよね。自分は面と向かって褒めるのがこっ恥ずかしくて苦手なのですが、「同じ時間と空間を過ごせたことに、感謝と誇り」を感じています(僕なりの最大の賛辞表現)
当日はTwitter広報役をやっていましたが、詳しくは@keithyokoyama山のブログをを見ていただくとよいです。反省点としては、海外からいらしたスピーカーをもっとクローズアップすればよかったと思います。自分の主観でしたが、英語喋れない人と日本語喋れない人の間に交流があまりなかったような気がしています。その間の橋渡しをするためにTwitterで「Mr. AAはXX社でAndroidのUIエキスパート的なことをしてます」みたいな紹介をすべきだった、来年はしよう、という気持ちです。
総じて#droidkaigiを見ていると、好意的な感想をいただけているので嬉しく思います。 次回はより大きなイベントになると思うので、自分としてはセキュリティ面でバリューを発揮出来るようにしていこうかな、と思います(すでにご相談いただいたりしているので)
今後のAndroidと私
最近Androidいじってねーんだよな〜というのが悩み。Authenticatorアプリを作ってみたいのと、Android Thingを攻めて行きたい気持ちはあります。後は、講演の最後でも言ったような安全なアプリを作るためのトレーニング、Androidマルウェアアプリの解析などやっていきたい気持ちです。
Demistoによって俺たちはSOCから解放されるのではないか #セキュリティ #chatops #demisto
結論: とりあえずSlackのintegrationでDemisto入れてみようず
Demistoとは
SOC的な業務は面白い事も沢山ありますが、それと同じくらいダルくもあります。例えば、「ドキュメントの作成」「進捗図の更新」「エビデンスの確保」「レスポンス前の細かい初期確認・トリアージ作業」。自分にとって、これらは出来ればやりたくない仕事です。というのも、フロー・マニュアルが定まっており、ちょっとコストをかければ誰でも再現可能な作業だからです。よって自動化したいと常々考えていたのですが、良さげなサービスを見つけたので紹介します。それがChatOpsベースのSOCサービス(「DEMISTO」)https://www.demisto.com/です。
サービス内容
DEMISTOのサービスは以下のものがあります。なお、ホームページからしか読めてないので、本当のところどうかは知らない
レスポンス製品と情報インベントリ製品との双方向な統合
「Bi-directional Integration with products for Information Enrichment and Response Actions」を直訳したので、頭痛が痛いみたいな表現になってしまい、お詫び申し上げます。
Twilio, Exabeam, Black Carbon, Slack, Active Directory, CheckPointのロゴから、恐らく「大量に外部送信してる通信(CheckPoint)かつ通常行動パターンとことなる挙動(Exabeam)を端末がしてて、Black Carbonがアラートあげてるから、管理者に連絡して(Twillio, Slack)、アカウントを一旦凍結(Active Directory)しつつ、穴を閉じ(CheckPoint)〜ましょ〜」のように、アクションとインベントリの連携を設定可能なんじゃないでしょうか。
自動プレイブックの生成と準備
DEMISTOは、インシデントが発生した場合、事前に定義した条件から、適切なPlayBookを選択します。このPlaybook内には複数のタスクが含まれており、自動で担当・期限が割り当てられるなど、それぞれの進捗確認・更新が容易になっています。各タスクについては、アサインされた担当がマニュアルに従って仕事をすることも可能ですが、Demistoが自動実行することもあるそうです。
セキュリティChatOpsによる調査と連携
これはタイトルそのままですが、過去分の調査と被ってないか自動でチェックしてくれたり、調査結果をエビデンス保存するなどの機能が、チャット上でワンクリックで実行可能なようです。便利です〜
ジャーナリングとエビデンスサポート
上述通り
自動ドキュメントによるレポート、評価、監査
自組織が抱えているインシデント全体のレポートを作成してくれるようです。抱えているインシデントの数、SLAの状況、インシデントの種類といったことを分かりやすいレポートにおとしてくれます。SOCやCSIRTそのもので役に立つより、チーム外にSOCの成果を報告する上でよさそうです。
Slack版Demisto
さて、上記の基本機能はFree Editionから限定的に使えるようになりましたが、仕事上のアカウントを使わねばならないので気軽に試せません。しかし、更に限定的とは言えSlack integrationもあります。こちらは気軽にインスコできるので試してみました。
Slack版で出来ること
脅威インテリジェンスの連携のみが可能です。脅威インテリジェンスとは、複数のセキュリティ関連データを集約したものです。マルウェアのハッシュ値や、レピュテーションスコアの低いIPアドレスなどをデータベース化したものですね。通常だとブラウザなどから入力しなければならないのですが、Slack版Demistoを使えばSlack上で完結します。アラートもSlackに流しておけば、作業を大幅に効率化できます。現時点では、IBM X-Force、Virus Total、Cylanceといった脅威インテリジェンスと連携しているようです。
デモ
- 事前準備: ここから自組織Slackに連携
監視するチャネルを指定する
- dbot(Slack連携すると追加されるボットアカウント)とのDirect Messagesで設定
join all/#channel1, #channel2
Verboseモードの設定
- dbotとのDirect Messagesで設定
- 実際に脅威インテリジェンスと照合した結果を通知するためには、これを設定する必要があります
verbose on #channel1, private1
IPを検査する
- dbotがjoin済み・verbose on済みのチャネルにIPを打ちます
サイトを検査する
- dbotがjoin済み・verbose on済みのチャネルにURLを打ちます
ファイルを検査する
- dbotがjoin済み・verbose on済みのチャネルにファイルをアップロードします
MD5ハッシュ値を検査する
凄い(小並感 以上です。機会があれば、Slack版ではないFree版も試して見ようと思います。
もしも社長がセキュリティ対策を聞いてきたら
もしも社長がセキュリティ対策を聞いてきたら(日経BP Next ICT選書)
- 作者: 蔵本雄一
- 出版社/メーカー: 日経BP社
- 発売日: 2015/06/30
- メディア: Kindle版
- この商品を含むブログを見る
上記のメモといっても、自分が流し読みした本に対するいいまとめがあったのでそれを元に構成変更・追記を実施。
・セキュリティは「監視的コスト」
上流の話
セキュリティ対策の優先度付け -> FMEA
リスク優先度算出時の構成要素:
- 発生頻度、影響度、防御困難度
- それぞれに対して4段階で点数化し、
- 優先度の高い内容から対策を施していく。
- 場合によっては、影響度のポイントを上げる。
セキュリティ対策の種別 -> Get Secure And Stay Secure
- Get Secure:セキュアにする
- システム化、教育といった対策
- Stay Secure:セキュアに保つ
- 検知、可視化、改善
セキュリティ対策による部分最適にならないためには
- 運用管理しやすい仕組み
- 他の階層と連携(認証基盤・アクセス制限・ファイアウォールなどの連携)
- 認証基盤の統合
- CISOの設置
セキュリティ対策のコスパ
アプローチ
- 守備範囲の限定
- 標準機能の活用
- アリモノを更新
- 多層防御
ソリューション選定 -> コンジョイント分析
- 対策から各アプローチから選定されたソリューションの特徴を抽出し、比較検討する
特長例
- ウイルス対策: 検出率、IT基盤統合、管理工数、ライセンス費用
- 出口対策: 提供形態、レポート、リセンス費用、認証ユーザー
多層防御
- 物理セキュリティ
- セキュリティポリシー
- 認証基盤
- NW境界
- 内部ネットワーク
- エンドポイント
- アプリ
- データ
セキュリティ対策の効果測定 -> PDCA
中長期: 計画達成のPDCA
- Plan
- Do
- Check
- Action
短期: 問題解決のPDCA
- Problem-Finding:問題発見
- Display:可視化
- Clear:問題解決
- Acknowledge:確認
セキュリティ対策の必要性や脅威の動向を経営者に説明する -> PEST分析
- Political:政治的環境要因
- Economic:経済的環境要因
- Social:社会的環境要因
- Technology:技術的環境要因
セキュリティ対策の4段階 -> NIST SP800-61
- 準備 → 検知・分析 → 根絶・復旧・封じ込め → 事件発生後の対応
- 検知・分析部分の強化が早期発見への近道。
セキュリティルール作りの際の考え方
- ポリシー:情報セキュリティに関する基本方針
- スタンダード:実施する対策
- プロシージャ:利用する製品や管理手順
ルール実施までの流れ
- ルール作成・みなおしの体制創り -> CFT(Cross Functional Team)
- ルール切り分け -> 技術的な強制ルール vs 強制しないルール
- ルールに応じた仕組みの実装 -> ペナルティや損害イメージ
ルール切り分けの方針 -> MMOから考える
- Measure/Motivation/Opportunity(MMO)から考える
- MotivationとOpportunityを下げることで発生頻度を下げるのがよい。
ルールの効果測定方法 -> DAGMARモデル
- 5段階の達成度合いを計測:
- 未知: まだ知られていない状態
- 認知: 存在を認知
- 理解: ルールの内容・背景を理解
- 確信: 良いモノ(重要性)だと確信
- 行動: 順守
企業文化・人材も視野に入れた包括的なセキュリティ対策: -> マッキンゼーの7S
- Shared Value(価値観):ソフト <- 他のSにも影響
- Strategy(戦略):ハード
- Structure(組織):ハード
- System(システム):ハード
- Skill(スキル):ソフト
- Staff(人材):ソフト
- Style(スタイル・社風):ソフト
要素技術
認証基盤構築のポイント
エンドポイントの一般的対策
- ウイルス対策ソフトの導入と定義ファイルの常時最新化
- パッチ(セキュリティ更新プログラム)の適用と更新
- 不正プログラムの起動防止(起動可能なソフトをホワイトリスト方式で管理)
- 不正通信の禁止
- 盗難・紛失による情報漏えいを防止(FDE/リモートワイプ)
安全・柔軟なIT基盤 -> 3A(AnyTime, AnyWhere, AnyDevice)
- AnyTime: 社内のどこでも -> 無線LAN, デジタル証明書(or パスワードとMACアドレス制限)
- AnyWhere: リモートワーク(部分アクセス(クラウド) or 完全アクセス(VPN))
- AnyDevice: BYOD(検疫ネットワーク)
セキュリティ対策を支援する機能
- OS標準イメージ
- インベントリ収集
- アプリやセキュリティ更新プログラムの配布(サイレントインストールとスケジュール)
- バックアップ
- 特定の実行ファイル・起動時間の把握(利用頻度のか把握や感染端末の特定など)
- ヘルプデスク支援
- 安全な構成
- 管理者権限のコントロール
例
- 操作ログを取得する
- 操作ログを分析する
- 管理者権限は申請時しか利用させない
- セキュアな領域での作業は必ず2人1組
もしも社長がセキュリティ対策を聞いてきたら(日経BP Next ICT選書)
- 作者: 蔵本雄一
- 出版社/メーカー: 日経BP社
- 発売日: 2015/06/30
- メディア: Kindle版
- この商品を含むブログを見る
大陽日酸に対するサイバー攻撃についてまとめてみた
イントロ
タイムライン
日時 | 出来事 | 備考 |
---|---|---|
2015/11 | 最遅でもこの時点で侵入済み | |
2016/3/11 | 外部からの不正接続(海外?)を確認。ウイルス感染を確認。サイバー攻撃と認知 | |
2016/3下旬 | ウイルスを駆除 | |
2016/4/28 | 警視庁に被害相談 | |
2016/4/29 | 流出範囲(可能性)の特定 | |
2017/1/1 | 公開報道。ホームページには未記載 | |
2017/1/5 | ホームページに公式発表公開。 |
攻撃の概要
ぱっと見、標的型攻撃っぽいところはある
攻撃の影響と成否
以下の事実が確認されている。
管理者権限の奪取
システム内の情報が外部から見れる状態。600台に対して、外部から管理者権限によるログインが可能だった。
- 情報の流出は
未確認、1万人の社員情報が流出した可能性あり
武器化
Delivery
Exploit
Install
成功 -> 最終的に4種類のマルウェアに感染していたところから。
C&C
(2015年11月までに)成功 -> 外部からの管理者権限を使った遠隔操作で、システム内の大半にあたる6百数十台のサーバーに接続できる状態。サーバーの一つから2回にわたり外部と不正通信が発生。
データの破壊・盗難
成功(可能性が高い) -> グループ国内従業員ら11,105人分の個人情報(社名・氏名・職位・メアド)など内部情報を複数の圧縮ファイルにまとめていた痕跡。サーバーの一つから2回にわたり外部と不正通信が発生。
被害額
窃取された情報から、直接的な被害額は発生していない。 ちなみに株価(1/4)時点では下がるどころか上がってる。世間が気づいてないか、気づいてるけど大して重要視してないか、それともトランプ効果があるからか、これから下がるのか。
原因
対策
- サイバー攻撃早期検知のための監視体制強化
- 管理者権限の搾取対策今日か
- 不正遠隔操作を某氏するための対策強化
- 大陽日酸ではないが、窃取された社員情報を利用した標的型攻撃に気をつける必要はありそう。
- 例えば「Title: [大陽日酸からの重要なお知らせ] Body: Hoge部長のFugaです。この度は云々カンヌン」みたいな。
所感
piyologはやすぎぃ!やっぱりpiyologはすごい。必ず1歩先をいかれている。後、具体的な数字(600台とか1万人の社員とかサーバ内情報とか)が出てて凄い。どこにあったんだろう公開情報。- 2017/1/1に報道公開した意図は不明。
株価への影響をみたい。1/4に要チェキこれ以上、続報でなさそう。- 最初に報道したところが、次の報道も早いと考えたほうがいいかも?
- JTBの時もそうだが、nikkeiは遅いかも。
- "当社の生産設備制御系システムは、基本的には今回サイバー攻撃を受けた情報系ネットワークおよびインターネットとは接続されておらず、今後もサイバー攻撃の影響を受けないと考えます。" おっ、そうだな。
- 警視庁公安部が不正アクセス容疑で操作...あっ(察し)
反省
- 検索方法: 大陽日酸 サイバー site:( OR OR OR OR )
- 検索方法: Google News
更新内容
- 2017/1/1: 初版
- 2017/1/3: 多数のニュースサイトで取り上げられるも、新しい情報なし。ホームページへの記載もまだ。
- 2017/1/4: 太陽日酸 -> 大陽日酸。ワロッシュ。どうりで検索も引っかからないはずやで。
- 2017/1/5: ホームページ上で公式発表。
Ref
ガス大手にサイバー攻撃 ウイルス感染、警視庁捜査 | どうしんウェブ/電子版(社会)
ガス大手にサイバー攻撃、管理者権限奪われる : 社会 : 読売新聞(YOMIURI ONLINE)
2016年の振り返りと2017年の目標
振返り
Keep
Problem
- やる気にムラがあった
- お金系(401k, NISA使い切らない)などがなかった
- ニュースソース・新聞を積極的に読んでなかった。忙しいとめんどくさがる
- ブログ/Qiita投稿などのアウトプットが2〜11月までなかった。
- 実家に中々帰れない。
- 将棋を8月頃に一回手放す。
- 個人Android/Webアプリを作れてません
- 機械学習も結局てを動かせず
Try
- 自分のスケジュールをもっとタイトに切る(コントロールする)。家が近いので深夜遅くまで働いてしまい、結果パフォーマンスとペースを崩してしまった。具体的には24時までに就寝し、6時起きを心がける。翌日のスケジュールは24時までに。
- 実家にコンスタントに帰るのは諦め、記念日を大切にするスタイルにする
- 持久力をつける(走ることを始める)
- 1〜2ヶ月に1つのテーマで技術勉強にとりくみ、それを少しづつアウトプットするといいかもしれない
- CISSPをやるか、機械学習をがんばるか、自分のアプリを作るか。毎日やれることと、週末などそれなりにまとまった時間が必要そうなもので区切れそう。
- 新聞を定期的に読む
- CISSP <- とる。
- 機械学習 <- 作る。自分の業務を楽にするものを作る。
- chatbot <- 作る。自分の業務を楽にするものを作る。
- サービス <- 作る(アイディアはあるけど手を動かせて無い状態)。クローラー
- AR <- やりたい
Googleが買収したセキュリティ企業
2016年12月までにGoogleが買収したセキュリティ企業を調べてみた。きれいな案件だけでなく、潰しにかかってるっぽいものもあって面白かった(小並感。企業買収をExitとするなら、対象企業がカバーできてないソリューションを開発するのがいいという事だけは分かった。アタリマエ。
要約
- ソース: https://www.cbinsights.com/research-google-acquisitions
- 調達額は各々シリーズの最初が違うのでアテにしないでください。
- 種別は私ジャッジでつけました。
企業名 | 種別 | 買収日 | 調達額 |
---|---|---|---|
GreenBorder Technologies | エンドポイント防御・仮想化 | 2007/5/10 | $18M |
Impermium | アンチスパム・不正アクセス対策 | 2014/1/16 | |
Interactive Security Group | レピュテーションススコアリング | 2012/6/3 | $9M |
Postini | エンドポイント防御 | 2007/9/10 | $16M |
reCAPTCHA | 不正アクセス対策 | 2009/8/6 | ?? |
SlickLogin | 不正アクセス対策 | 2014/2/17 | $20K |
Spider.io | マルウェア検知 | 2014/2/21 | ?? |
Widevine Technologies | 著作権保護 | 2010/12/3 | $44M |
Zynamics | OSS | 2011/3/2 | ?? |
VirusTotal | データマイニング | 2012/9/9 | ?? |
GreenBorder Technologies
- メールやウェブサイトの閲覧をオンラインサンドボックスで限定することにより、エンドポイントをマルウェア感染などから防ぐソリューション
- システム管理者が管理サーバで、信頼できるネットワークとアクセス先を定義することで、マルウェア防御、不正なダウンロードを防ぐことができるらしい。
- チームはChromeのSandbox機能に統合された
Imperium
- アンチスパム・オンラインのアカウント防御サービス
- 不正登録、不正ログイン、アカウントハイジャック、ソーシャルスパムから防御する
- 買収前はPinterestやTumblrが使ってたが、今はサービスを停止している。
- Google内のアンチスパムグループに統合されたらしい
Interactive Security Group(KikScore)
- 当該サービスに登録した中小企業のレピュテーションスコアを提供することで、登録企業はユーザーに対して信用度を伝えることができる
- 儲からなそうとおもったら、Total Funding $0だった...
- どうもGoogleは特許を買っただけで、KikScoreの顧客にはGoogle's Trusted Store製品を買うように勧めているらしい。尚、KikScoreからマネジメント層は1人も移籍してないらしい。闇が深...おっと誰か来たようだ。
Postini
- ウイルス・スパム・フィッシングから、メール・インスタントメッセージ・ウェブ上のメッセージを暗号化することでプライバシーを保護する
- 又、通信をアーカイブすることでコンプライアンスを保つ
- postini.comにアクセスするとGsuiteにリダイレクトされるので、Gmailやチャットをアーカイブする機能に統合されたっぽい。
reCAPTCHA
- 説明不要。これ。
- 企業名継続案件
SlickLogin
- 高周波音を使ってウェブサービスのログインをセキュア化するもの。謎。
- 少なくともGoogleの2段階認証にはまだ登場していない...
- slicklogin.comにアクセスしようとすると403エラーになる。謎
Spider.io
- 不正なオンライン広告を経由して感染するマルウェアに対するソリューション
- 感染したPCを検知することで、オンライン広告が世にばまかれることを防ぐ
Widevine
- デジタル著作権管理機能(DRM)を提供する。これでアプリ内の動画を保護する。
- GoogleのChromeブラウザ/Chromecast/Daydreamなど様々なサービスで利用されている
- Androidにおいては、Nからは全く対応しなくなるらしい。 "starting with Android 6.0, there is no expectation of a Widevine Classic client to exist on any Android device." オウイェ〜。
- 企業名継続案件その2
VirusTotal
- え、Googleが買収してたの?
- 説明いる?要らない気がする。これ。
- 企業名継続案件その3
Zynamics
- え、Googleが買収してたの part2。
- BinDiffやBinNavi(リバースエンジニアリングツール)などの有名なツールを無料で提供している。
- 企業名継続案件その4
AndroidのConcealライブラリの中身を読む
色々あれがこれなので、Facebookが出している暗号化ライブラリ「Conceal」のソースコードを読んでみました。
- 使い方については、こちらの記事を参照いただくといいと思います。
Concealとは
- Facebookが開発したライブラリです。共通鍵暗号アルゴリズム AES(256bit)と暗号利用モード GCMを用いた暗号化処理を代行します。
- 基本的には一箇所に保存され、転送されない想定のデータを対象にしています。
- https://github.com/facebook/conceal#encryption
Concealライブラリの中身
Concealのgithubページ・上記Qiita記事に載っているので実装は割愛しますが、大きく4ステップがあります。
それでは各ステップでConcealが何をしているか読み込んでいきましょう。
KeyChainインスタンスの生成
KeyChainは共通鍵や関係するデータのライフサイクルに関わるメソッド群を定義したインターフェースです。これを実装したSharedPrefsBackedKeyChainインスタンスがまず生成されます。ファイル名の通り、SharedPrefをベースにしていますが、暗号化に欠かせない疑似乱数生成器(PRNG)の生成と、暗号化時の鍵長を設定します。
PRNGの生成 と 既知の脆弱性対応
- 該当コード
# SharedPrefesBackedKeyChain.java SecureRandomFix.createLocalSecureRandom()
PRNGはOpenSSLを利用して生成されますが、Jelly Bean(16~18)には初期化プロセスに脆弱性がありました。 この脆弱性をつくことで暗号文の強度が低下し、BitCoinアプリ内のウォレットの盗難などができてしまう模様です。Googleはこれへの対処方をDeveloper Blogに公開していますが、これをConcealがカバーしてくれています。
private static void tryApplyOpenSSLFix() { try { // Mix in the device- and invocation-specific seed. Class.forName("org.apache.harmony.xnet.provider.jsse.NativeCrypto") .getMethod("RAND_seed", byte[].class) .invoke(null, generateSeed()); // Mix output of Linux PRNG into OpenSSL's PRNG int bytesRead = (Integer) Class.forName( "org.apache.harmony.xnet.provider.jsse.NativeCrypto") .getMethod("RAND_load_file", String.class, long.class) .invoke(null, DEV_URANDOM, 1024); if (bytesRead != 1024) { throw new IOException( "Unexpected number of bytes read from Linux PRNG: " + bytesRead); } } catch (Exception e) { throw new SecurityException("Failed to seed OpenSSL PRNG", e); } }
暗号化時の鍵長を設定
crypto\CryptoConfig.java
で、鍵長・初期化ベクトル長・タグ長の組み合わせがenumで定義されています。とはいえ、その組み合わせは2通りしかなく、しかも鍵長にしか違いはありません。2016年4月にリリースされたv1.1から、デフォルト推奨の鍵長が256bitになりましたので、基本はCryptoConfig.KEY_256
を使いましょう。
- デフォルトenum:
- cipherID: 2
- 鍵長: 256bits
- 初期化ベクトル長: 12bits
- タグ長: 16bits
Cryptoインスタンスの生成
前述のKeyChainをセットしAndoidConceal().get().createDefaultCrypto(keyChain)
で、生成しています。AndroidConceal().get()内でまた SecureRandomFix.createLocalSecureRandom()
を呼び出しています。おそらくこれは旧バージョンと新バージョンでの使用方法の差異に発する実装かと思われます。また、Cryptoインスタンス生成時に暗号化アルゴリズム(AES-GCM)が決定されます。今後、これが拡張されて他のアルゴリズムや暗号利用モードが利用できるようになる...ことはないでしょう。多分。
ライブラリのロード状況チェック
ConcealのAESアルゴリズム・GCMはCで書かれているため、Conceal内でNativeライブラリ"crypto"がロードされます。このチェックをcrypto.isAvailable()
がしています
暗号化
Concealで暗号化は、平文を書き込む出力ストリームをラップすることで実現されます。デフォルトの実装では、Cryptoインスタンスを通じてBufferedOutputSreamをラップし、そのストリームに平文を書き込む形になります。
出力ストリームのラップ
実際のラップは、Cryptoインスタンス内のmCryptoAlgo変数が担当します。
# Crypto.java public OutputStream getCipherOutputStream(OutputStream cipherStream, Entity entity, byte[] encryptBuffer) throws IOException, CryptoInitializationException, KeyChainException { return mCryptoAlgo.wrap(cipherStream, entity, encryptBuffer); }
wrap内では、KeyChain内のPRNGから初期化ベクトルが生成され、他のメタデータと一緒に、ラップされる前の出力ストリームに書き込まれます。また、共有鍵もこのタイミングで生成されます。KeyChainのgetCipherKey()は、 maybeGenerateKey()を呼び出し、鍵を生成(もしくは取得)し、SharedPreferenceに保存します。
# CryptoAlgoGcm.java @Override public OutputStream wrap(OutputStream cipherStream, Entity entity, byte[] buffer) throws IOException, CryptoInitializationException, KeyChainException { cipherStream.write(VersionCodes.CIPHER_SERIALIZATION_VERSION); cipherStream.write(mConfig.cipherId); byte[] iv = mKeyChain.getNewIV(); NativeGCMCipher gcmCipher = new NativeGCMCipher(mNativeLibrary); gcmCipher.encryptInit(mKeyChain.getCipherKey(), iv); cipherStream.write(iv); } # SharedPrefsBackedKeyChain.java @Override public synchronized byte[] getCipherKey() throws KeyChainException { if (!mSetCipherKey) { mCipherKey = maybeGenerateKey(CIPHER_KEY_PREF, mCryptoConfig.keyLength); } mSetCipherKey = true; return mCipherKey; } private byte[] generateAndSaveKey(String pref, int length) throws KeyChainException { byte[] key = new byte[length]; mSecureRandom.nextBytes(key); // Store the session key. SharedPreferences.Editor editor = mSharedPreferences.edit(); editor.putString( pref, encodeForPrefs(key)); editor.commit(); return key; }
その後にGCM特有のデータと一緒に、AES-GCMで入力データを暗号化されるNativeGCMCipherOutputStreamが生成されます。
# CryptoAlgoGcm.java @Override public OutputStream wrap(OutputStream cipherStream, Entity entity, byte[] buffer) throws IOException, CryptoInitializationException, KeyChainException { byte[] entityBytes = entity.getBytes(); computeCipherAad(gcmCipher, VersionCodes.CIPHER_SERIALIZATION_VERSION, mConfig.cipherId, entityBytes); return new NativeGCMCipherOutputStream(cipherStream, gcmCipher, buffer, mConfig.tagLength); }
暗号化
上記で生成したNativeGCMCipherOutputStreamに平文がwriteされると、NativeGCMCipher.updateが呼ばれ、gcm.c内のJava_com_facebook_crypto_cipher_NativeGCMCipher_nativeUpdateAadで暗号化されるのかと思われます。AndroidのNDKの仕組みに詳しくないので、間違っていたら教えて下さい。
# NativeGCMCipherOutputStream.java @Override public void write(byte[] buffer, int offset, int count) throws IOException { if (buffer.length < offset + count) { throw new ArrayIndexOutOfBoundsException(offset + count); } int times = count / mUpdateBufferChunkSize; int remainder = count % mUpdateBufferChunkSize; for (int i = 0; i < times; ++i) { int written = mCipher.update(buffer, offset, mUpdateBufferChunkSize, mUpdateBuffer, 0); mCipherDelegate.write(mUpdateBuffer, 0, written); offset += mUpdateBufferChunkSize; } if (remainder > 0) { int written = mCipher.update(buffer, offset, remainder, mUpdateBuffer, 0); mCipherDelegate.write(mUpdateBuffer, 0, written); } }
以上が、一般的なConcealの暗号化が行われるステップになります。
Conceal - 他の機能
より単純な暗号化の実装
Cryptoインスタンスの生成までは同じですが、そのあとはただ一行「encrypt()」でおわる実装方法です。もう片方との違いは、出力ストリームが受け取れるバイト長が固定であることです。一回生成したら変更がないイミュータブルなデータ、もしくはハッシュ化したデータを暗号化したい時に使えるかもしれません。
KeyChain keyChain = new SharedPrefsBackedKeyChain(context,CryptoConfig.KEY_256); Crypto crypto = AndroidConceal.get().createDefaultCrypto(keyChain); crypto.encrypt(plainTextInByte, Entity.create("unique_id"))
パスワードベースの鍵の生成
Concealは基本的に鍵の生成・初期化ベクトルの作成など、暗号化で必要な処理は全てやってくれます。もし、そういった利便性を投げ捨ててオリジナルな鍵を作りたいのであれば、パスワードから生成することができます。しかし、あくまでも鍵を生成するところまでで、そのあとの暗号化処理、初期化ベクトルの作成、鍵の保存を全て自前で実装する必要があります。
AndroidConceal.get().createPasswordBasedKeyDerivation() .setIterations(10000) .setPassword("P4$$word") .setSalt(buffer) .setKeyLengthInBytes(16) // in bytes .generate();
MAC値の取得
Concealを利用すれば、デフォルトの暗号利用モードがGCMになってます。GCMは認証付きアルゴリズムなので、MAC値の計算は必要ありません。しかし、パスワードベースの鍵の生成をした場合、複合時に完全性・認証をしたほうがいいので、その場合はこれをつかうといいと思います。なお、複合に完全性・認証チェックがなぜ必要なのかを知りたい場合は、オラクルパディング攻撃でggrと良いでしょう。
OutputStream fileStream = new BufferedOutputStream(new FileOutputStream(file)); OutputStream outputStream = crypto.getCipherOutputStream(fileStream,Entity.create("entity_id")); crypto.getMacOutputStream(outputStream,Entity.create("unique_mac_id")); // probably outputStream.write(plainTextBytes); outputStream.close();
Concealを使うにあたって気をつけたいこと
最後にConcealを使うにあたって気をつけたいことを書きましょう。
- 上述しましたが、ver1.1から256bit鍵長が推奨されています。記事の中にはver1.1以前のもあるので気をつけましょう。
- 鍵をSharedPreferenceに保存しているので、Root化された端末では抜かれてしまいます。
- API18以降を対象とするならおとなしくKeyStoreに保存しましょう。その場合ユーザーが入力するパスワードがなければ開けない
- というより、大事な情報は基本サーバに起き、Android端末には保存しないようにしましょう。必要な時にだけfetchしに行きましょう。
- もし、サーバにおけない場合は...いい案があったら教えてください。Root化された端末では利用できないようにする...とか?