Got Some \W+ech?

Could be Japanese. Could be English. Android, セキュリティ, 機械学習などをメインに、たまにポエムったり雑感記載したりします。

Financial APIs Workshop 2018 と Japan/UK Open Banking and APIs Summit 2018参加レポ #fapisum

Authlete社の創業者 川崎さんにお招きいただき次の2つのイベントに参加してきました。 (川崎さん、ありがとうございます!)

⁃ 7/24(火): Financial APIs Workshop 2018
⁃ 7/25(水): Japan/UK Open Banking and APIs Summit 2018

両日とも満席であり金融機関向けAPIやFAPIへの関心が高まっていることを実感できる2日間でした。 内容は7/24は技術者を対象にした、7/25はよりエグゼクティブを対象としたThe Open Banking Implementation Entity(OBIE)やFAPIを中心としたセッションになっていました。本ブログはその2日間をまとめたものになります。

OBIE概要

金融機関に預けられた取引履歴や本人情報などの金融データはユーザーのものになりますが、従来は金融機関がそれらをある意味、勝手に利活用していました。それを本来の所有者であるユーザー自身が制御できるようにすべし。ローコストで機会を増やすべし。そういった考えからオープン銀行APIの標準やセキュリティやセキュリティアーキテクチャを策定している in イギリスがOBIEです。 OBIEは所属団体が 継続的に仕様に満たされた実装されていることを保証 することで、一時的に準拠可能な企業を量産するのではなく、エコシステムを築くことを1つの目標としています。

OBIEの標準は大まかに4つのカテゴリに分けられます。

  1. Identity: 信頼されたOBIE参加団体と顧客(APIクライアント?)に関するリストとAPI。アプリ登録や登録された銀行やFintechの情報(含むJSON形式のデータ)のみならずSwaggerファイルも置かれているようです。
  2. Reference Data: 銀行の商品や説明(eg ATMの場所)といったオープンにすべきデータに関するAPI
  3. Users Data: 口座や支払い情報に関するRead/Write API

  4. Security: 認可や認可の委譲にかんする同意を含めたセキュリティ標準

OBIEは2016年に発足したばかりですが、2018~2018は様々な仕様の追加・変更があるようです。 AIS(Account Information Services)やPIS(Payment Initiation Services)のPSD2(※)口座や通貨への対応、CIBA(Client Initiated Backchannel Authentication Profile)によるユーザー同意とクライアントが認可トークンを取得するデバイスをDecoupledする仕様、失効通知…などがもりもりです[1: p9]。

※ 銀行によるオープンAPIを事実上義務付けた決済サービス指令のv2

こちらを整備していきつつ、開発者やベンダーへのサポートを充実させていくようです[1: p.15]。

OBIEの技術スタック

全ての仕様はオンラインに公開されています[3]が、ベースはOAuth2.0[4]のフレームワークです。

OAuth2.0++

OAuth2.0についての基本的な解説もありました[9]が、基本的には@TakahikoKawasakiさんのQiita[4]を読めばおkです。しっかり理解したいのであればRFCを読むといいでしょう。ちなみに、私は両方読んでいるので完全に理解しています(していない)。 他にもある主体について「この主体はこの情報があるから真正だぞ」と主張するための情報を表現するJWT[7]についての解説もありましたが、これはRFC7519とともにAuth0が発行している”JWT Handbook”を読んで見るのもいいかもしれません。私は両方(略)。

OAuth2.0(RC674)はフレームワークです。すなわち場面やケースにあわせて、オプションを付与したり拡張することができます。逆に言うと、フレームワークのみでは十分出ないケースがあります。

金融APIも例外ではなく、金融機関として満たさなければいけないセキュリティの要件または ”プロファイル”になります。Nat Sakimuraさんの講演[10]によると、RFC6749単独ではプロファイルは満たせません。なぜならOAuth2.0における認可フローの各ステージにおいて、認証(メッセージ、送信者、受信者、利用者)などが考慮されてないからです。具体的に言うと、認可リクエストやレスポンスの保護といった部分が十分ではありません。

またOauth2.0では許容されていたBearer Tokenも盗難されたら誰であろうと利用可能になってしまうなどの問題もあります。そこで、従来のOAuth2.0に加えPKCE + Hybrid Flow + JWS AuthZ Request(JAR) + MTLSを拡張機能としてとりこむことで、金融機関向けのセキュリティ要件(プロファイル)を満たしています。 なお、上記の話はNat Sakimuraさんの講演ではFAPIのread/write security profileの文脈ででてきましたが、OBIE自体はそれをベースにしている[13]ので大きくずれてはないと思います。私の知る限りではOBIEでは、トークンが発行要求者とひもづいているSender Constrained TokenのうちToken Bindingについて触れてないぐらいだと思います。

このような仕様を認可サーバーをAPIで提供するAuthleteさんはver2.0で実装したようです。他にもAuthleteさんはFAPI受けスコープ属性の管理機能を作成したり、新規クライアント認証の方式を追加したり、MTLS証明書および検証ができるような機能が追加されたようです[18]。

その他OBIEの仕様・サービス

上記だけでなく次に紹介するような仕様やサービスがありました。恥ずかしながら、私は知りませんでした。

さて、OAuth2.0はRedirectを前提としたフレームワークになっていますが、EU各国では様々なバリエーションが登場しています。 例えば、POSで支払いをするクライアントがユーザーの管理下にないことを想定し、同意や認証はユーザーの認証器で、トークンの取得はOauthクライアントに分離(decoupled)するようなアプローチもあります。 また、こちらはあまりよくわかっていないですが、”認証した結果を「パスワード」として送信する[14, p.18]” というようなEmbeddedな方法もあるようです。

個人的に一番newだったのはintent registration endpointです。探してもあまり情報がでてこなかったので多分に推測がありますが、AuthZリクエストを送る前に、認可目的をサーバーに伝えるような仕様です。例えば、「Aさんに$100を送信する」行為をしたい場合、その目的をクライアント経由で送りintent_idを取得します。認可リクエスト時にはintent_idを記載したリクエストをします。こうすると例えば「同意を得るために必要な個人情報の取得」といったユースケースにも利用できるのかと思われます。

Open Banking Conformance Suite[15]も素晴らしかったです。これは先述した”所属団体が継続的に仕様に満たされた実装されていることを保証”した状態を保証します。これは、FAPIやOBIEのAPIプロファイルに対するテストだったり、IdPやFIntechなどのRPにも適用できるテストです。これにより、コストや準拠状況を一瞬で可視化できるようになります。これがあれば、各金融機関がFintech業者のセキュリティ担当に押し付けるフォーマットがそれぞれ完全にことなり評価ポイントもまちまちの全く本質的でないセキュリティチェックシート in エクセルを駆逐できるようになると思います。

そして、Open Banking Directory[16]。これ、個人的にOpen Banking Conformance Suiteと同じくらいワクワクしたがNew内容なので、詳細はもっと調べてからにしたいです。サマリーとしては、Regulators(金融庁のような監督組織?)、銀行、Fintech企業などのサードパーティが、それぞれが他のDirectoryメンバーとやりとりするためのクレデンシャル(例: 登録したアプリのクレデンシャル)や証明書およびその他属性データを登録する場所、それがOpen Banking Directoryです、多分。

まとめ

以上のように、今回の2つのイベントをひっくるんだ#fapisummitに参加してまいりました。 英国では着々と金融APIの発展が進んでいるようです。日本でも同様に整備しよりスケーラブルでセキュアな金融基盤がうまれることを願っています。

私自身もFAPI Part.1(Read Only API Security Profile)について「俺らの愛したセキュリティ」で著しました。もしよければ次のリンクからご購入してみてください。 https://booth.pm/ja/items/864595

また、技術書典5にも無事当確しました。その際にはFAPI Part 2(Read and Write API Security Profile)について書くやもしれません。その際は、是非当ブースまでご訪問ください。

Reference

[1] Ralph Bragg, Open Banking for Developers. https://www.slideshare.net/fintechlabs-io/open-banking-for-developers [2] Tasuya Kudo, Trends in Banking APIs, https://www.slideshare.net/fintechlabs-io/banking-apis-authorization-practice [3] Https://openbanking.atlassian.net/wiki/ [4] Takahiko Kawasaki, https://qiita.com/TakahikoKawasaki [5] The OAuth 20 Authorization Framework(RFC6749), https://tools.ietf.org/html/rfc6749 [6] OpenID Connect Core 1.0 incorporating errata set 1, http://openid.net/specs/openid-connect-core-1_0.html [7] JSON Web Token(JWT), https://tools.ietf.org/html/rfc7519 [8] JWT Handbook, https://auth0.com/resources/ebooks/jwt-handbook [9] Takahiko Kawasaki, OAuth OIDC Basics, https://www.slideshare.net/fintechlabs-io/oauth-oidc-basics [10] Nat Sakimura, FAPI and Beyond, https://www.slideshare.net/fintechlabs-io/fapi-and-beyond [11] OAuth2.0, https://oauth.net/2/ [12] Financial-grade API (FAPI) WG, http://openid.net/wg/fapi/ [13] Open Banking Security Profile - Implementer's Draft v1.1.2 , https://openbanking.atlassian.net/wiki/spaces/DZ/pages/83919096/Open+Banking+Security+Profile+-+Implementer+s+Draft+v1.1.2#OpenBankingSecurityProfile-Implementer'sDraftv1.1.2-OAuth2.0,OIDCandFAPI [14] Tatsuya Kudo, Trends in Banking APIs, https://www.slideshare.net/fintechlabs-io/banking-apis-authorization-practice [15] Joseph Heenan, FAPI/Open Banking Comformance, https://www.slideshare.net/fintechlabs-io/fapi-open-banking-conformance [16] Open Banking UK Identity Product, https://www.slideshare.net/fintechlabs-io/the-open-banking-identity-product [17] AUTHLETE 社、「金融グレード API」導入促進へソリューション提供開始 , https://prtimes.jp/main/html/rd/p/000000007.000024448.html [18] Justin Richer, Authlete FAPI Implementation Part 1 https://www.slideshare.net/fintechlabs-io/authlete-fapi-implementation-part-1

July Tech FestaでAWS GuardDutyの話してきた

本日(2018/07/29)、July Tech Festa 2018で「GuardDutyを使ったサイバー攻撃の検出と分析」の話をしてきた。 とりあえず、今年はじめにかんがえていたインフラ関係でアウトプットを出す約束を守れてよかったとおもう、ふいー。 なお、buildersconは落ちた模様...

GuardDutyを使ったサイバー攻撃の検出と分析.pdf - Speaker Deck

今北産業

だいたい以下について話た。

  • AWSでなぜGuardDutyを使うのか
  • 実際のところのGuardDuty
  • 今後、どのように発展させていきたいのか

AWSでなぜGuardDutyを使うのか

  • AWS(というよりIaaS)の世界観だから発現したリソースには、それに応じる脅威がある
  • よって、従来の検知メカニズムに追加対応をする必要がある
  • 要は優先度とリソースの話であり、それを考えると(まだEC2とIAMにしか対応してないといえど)検知の要件からダッシュボード、そして他リソース(LambdaとかLambdaとかLambdaとか)との連携を容易にできるAWS GuardDutyはなかなか良いソリューションになりうる

実際のところのGuardDuty

まあセオリーはセオリーなので、じゃあ実際使ってどうなのか?という話をした。

  • じっさいやすい!(ニンジャスレイヤー風) -> 従来の外部SOCサービスを完全に置き換えた
       * Q&Aのときに検知漏れはないか?ときかれたときに、「そもそも要件がなかったから問題ない」とかいう頓珍漢な回答をしてしまった。
       * ちゃんとGuardDutyテスト攻撃スイート↓があり、そこでテストをすることで検知漏れがないことを確認した、という回答にすればよかった。なお、ちゃんとCloud Formationが動かなかったのでissueをたてたものの一ヶ月弱放置されている模様。
    

github.com

     * まあ、どっちにしろ社内Pentestのとき外部SOCサービスはかすりもしなかったので問題ない。
  • SOCの天敵である誤検知もほぼない -> あったらフィルター作って自動Archiveすればいい。
  • インシデントレスポンスをコード化可能 -> はいはいLambda。とりあえずやったのは以下。基本的にはAPI叩いてるだけです。必要なのは適切なフローを確立させておくこと。あとはただの実装(とデプロイと運用とIAMの設定とその他hogehoge)
      1.  JIRAにインシデントチケット作成
      2. 重要度に応じたSlack通知
      3. Pager Duty連携 <- 正直最近はJIRAと役割がかぶって2重管理になってるなぁと思っている。どちらかによせたい。
      4. 自動的にスナップショットとって、フォレンジック用インスタンスを隔離VPCにたてるところまで書いた。尚、社内ではまだ調整中の模様。
    

今後のGuardDuty

要はとりあえずGuardDutyオンにしておきなよ、影響はないし、という話だが、まだ成長段階。 大きく分けて当社の実装とAWSへの要望になる。

当社の実装

  • インテリジェンスデータを食わせたい
  • JIRAとPagerDutyの役割をはっきりさせたい
  • 全体的にもっと綺麗にしたい <- 今、Goでかいたのをzipにしてuploadする作業を手動でやってるので...
  • Lambdaの構成を考えたい <- モノリシックなLambdaにするか、Pipeでつなげるようにするか。あとエラー処理
  • 実際に攻撃スクリプトを作成
  • https://github.com/awslabs/amazon-guardduty-tester でissueに対する反応がなければ、おれがterraformとgoスクリプトで作りはじめる。

AWSへの要望

  • https://github.com/awslabs/amazon-guardduty-tester <- 頼む!反応してくれ!
  • S3やRDSも頼む(Macieか?)
  • IPブラックリストホワイトリストやめない?ゼロトラストでいかないか
  • 端末情報連携したいなーJamfとかJamfとかADとか。これも基本ゼロトラスト対応のため
  • CloudTrailの移動とかRegionまたぎが地味にめんどいで、マスターアカウントにそれらの情報も集約したい
  • たのむ!各FInding TypeとActionごとのJSONスキーマ例をちゃんと出して...Lambdaのエラーでしか気づけない...
  • 特定の送信元IP/宛先ポートへのDeny通信急増は検知したい。今はGuardDutyの仕様として、6時間毎に結果をまとめられて送るのでわからん。

といったような話をしてきました。

反省

ポジ

  • 自己紹介ページを削ってよかった。あれで30秒、本当に話したいことを増やせた
  • コードの記載はしたけど、あえて読み飛ばした。後ろの人は絶対みえないよね
  • 検知内容の詳細の解説も削ってよかった
  • 時間ぴったしに終わる能力が向上してきた。

ネガ

  • もうちょっとしゃべる練習すればよかった。いったりきたりする説明が多かった気がする
  • 今後のGuardDutyでは文字に頼りすぎた。もうちょっとビジュアルを挟むべきだった
  • 普通に当社の求人出し忘れた

今後はGuardDutyでやりたいことを増やしつつ、もうちょっとCloud NativeやOAuth/OIDC/FIDOなことをやっていくつもり。

RSAカンファレンス 2018のお薦めスライド

RSAカンファレンス2018のスライドが公開されていたので、ざっと一通りみました。 おもに私が面白い・役に立ったなと思うもののまとめをします。

オペレーション

Incident Response In the Cloud

クラウド上でSANS GCIHをするには、というテーマの発表です。Preparation, Detection, Containment, Recoveryのフェーズでの対応をクラウド向けに再構築しているもので、とても勉強になりました。

  • Preparation
    • レスポンスチーム用のIAM
    • ログ・エビデンス用のS3バケットの準備
    • 全アカウントでのロギングやCloudWatch
    • SGでレスポンスチームしか使えないインバウンドな通信。アウトバウンドは必要なときのみ開ける。
  • Detection
    • SIEM, CASB
    • CloudTral(API呼び出し元、時間、呼び出し元IPアドレス、レクエストパラメタとレスポンス)
    • Security Monkey
    • 見たいログ(ユーザーの疑わしい行動、switch role時の行動、新しいリソース、不審な行動の時間帯、失敗したアクセス、Get/Describe/Listは可能であれば飛ばす)
  • Containment
    • Tag付けして調査
    • 隔離VPCにいれtり、隔離SGを適用
    • EC2のEBSをスナップショットする(フォレンジックEC2にアタッチする)
    • メモリはMargarita Shotgunなどで取得
    • SANSのInvestigative Forensic Toolkit(SIFT)の構築. EBSスナップショットをアタッチ。
    • ThreatResponse Suiteを使うのも良い(AWS_IR, Incident pony, Margarita Shotgun)
    • Digital Forensic Analysis of Amazon Linux EC2 Instances
  • Erradication
    • Terraform destroy && Terraform apply

他にも、github.com/tradichel/AWSSecurityAutomationFrameworkなどが良さそう。

https://www.rsaconference.com/writable/presentations/file_upload/air-w14-incident-response-in-the-cloud.pdf

From SIEM to SOC: Crossing the Cybersecurity Chasm

昔はエンドポイントはAVなどで防御だけやっておけばよかったけど、最近は防御も検知も一次対応もやらないとね、と主張したスライドはよかったです。まあ、これは従来のネットワーク上の検知を否定するものではなく、より詳細な対策をするにはエンドポイントもみていこう、という話なのでとてもまっとうな話だと思います。Carbon BlackというEDRベンダーのプレゼンなのですが、「AntiVirustは死んだ」のような脳死に営業文句がなかったのは相当ぷらすでした。

https://www.rsaconference.com/writable/presentations/file_upload/spo3-r04-endpoint_security_and_the_cloud-how_to_apply_predictive_analytics_and_big_data.pdf

Identity

Risk-based approach to deployment of omnichannel biometrics in Sberbank

Biometricksの話です。Biometricsによる認証メソッドはすでに、ハイプ・サイクルにおける実用段階まで到達していて

ただ、欧州では可用性が低いことと偽造可能なことからBiometricsは信用されておらず、Something You Haveのカード等のSomething You Haveを採用しています。まあね〜。

そういったBiometricsにおける課題から、Riskベースの認証について、そのワークフロー、リスクスコアの計算モデル、ユースケースの取組が紹介されています。

余談ですがJuniper, TOP10 Disruptive technologies in fintechがよい読み物でした。

https://www.rsaconference.com/writable/presentations/file_upload/idy-w02_risk-based_approach_to_deployment_of_omnichannel_biometrics_in_sberbank.pdf

Adventures in OpenBaking: Understanding OAuth and OpenID Connect Client Ecosystems

Open Bank in イギリスにおける現状と課題の概要を掴むのによいです。 半分ほどのスライドがOAuth 2.0 Dynamic Client Registration(RFC 7591 )に費やされていました。Dynamic Client Registrationは、認可サーバーに対してクライアントが直接メタデータを登録することで、クライアントクレデンシャルを受け取る仕様です。 https://www.rsaconference.com/writable/presentations/file_upload/idy-r04_adventures_in_open_banking-_understanding_oauth-openid_client_ecosystems.pdf

Google And Microsoft Debut: Replacing Passwords w/ FIDO2 Authentication

FIDO2の紹介ですね。まあ、そこまで新しいことはなかったかな...が、おぬぬめです。

https://www.rsaconference.com/writable/presentations/file_upload/idy-f02_mcdowellfinal.pdf

Detection of Authentication Events involving stolen enterprise credentials

不正な認証イベントを検知するための、機械学習モデル及びインフラの考え方についての実用的なお話になるかと思います。特長としては、認証イベントの発生時間、同時間帯の端末上のイベント、通信イベント(ポート毎のパケット・バイト・接続数、DNSイベント)、同時間帯の認証側サーバーのイベントになります。これをランダムフォレスト、ロジスティック回帰、Naiive Bayes, マルチレイヤーパーセプトロン、SMOを使って学習させた模様。

特にイベントデータのストリームから、同データを抽出し、アップデートをかけていくかは参考になりました。

でも、stolen enteprise credentialsはちょっと関係なかったかな...?

https://www.rsaconference.com/writable/presentations/file_upload/idy-f03_detection-of-authentication-events-involving-stolen-enterprise-credentials.pdf

OAuth2.0 Threat Landscape

RFC6819の内容ですね。下記の攻撃(脅威)および対策についてまとめたものです。

  • CSRF攻撃
  • Token/Code漏えい
  • Token使い回し

https://www.rsaconference.com/writable/presentations/file_upload/idy-w04-oauth-2.0-threat-landscapes.pdf

Can blockchain enable identity management?

Portableな個人の属性を個人が選択して使い、その属性情報と信頼スコアをBlockchainに残すSelf Sovereign Identityなしくみです。最近だとMicrosoftが活発に取り組んでいる気がします。

https://www.rsaconference.com/writable/presentations/file_upload/idy-r12_can-blockchain-enable-identity-management.pdf

Identity In Ten Hundred words

Identity周りにおける用語解説集です。これだけでプレゼンがなりたったかよくわかりませんが、辞書的に使うのにはよいです。

https://www.rsaconference.com/writable/presentations/file_upload/tv-t08-identity-in-ten-hundred-words.pdf

その他

Transfer Learning: Repurposing ML Alogorithms from different domains to cloud defenese.

Microsoftにおけるクアウドを防御するための機械学習に関する発表です。正直難しかったのでまとめられてませんが、悪意あるPowershellを検知する手法など興味深いかったです。

https://www.rsaconference.com/writable/presentations/file_upload/csv-w02-transfer-learning-repurposing-ml-algorithms-from-different-domains-to-cloud-defense.pdf

技術書典4に出店した as セキュア旅団

技術書典4にサークル名「セキュア旅団」として、新著「俺らの愛したセキュリティ」を販売しました。

f:id:kengoscal:20180428022928p:plain

お立ち寄りくださった皆様、ご購入いただいた皆様、誠にありがとうございました。万が一入手できなかった方のためにbooth(など)でダウンロード購入できるようにする予定ですので、お待ち下さい。

本投稿では、備忘録として次の2点についてまとめます。

  • 執筆内容
  • サークルとして取り組んだこと

執筆内容

「セキュア旅団」は自分の好きなセキュリティ技術をアウトプットしていくことを目的としています。世の中にインパクトを与えるか、インフルエンサーになるか、そういった結果は大事ではなく、ただアウトプットを至上とします。そんな「俺得」技術書を今回も書かせて頂きました。

前回の「ニッチセキュリティー明星へ登る」の著者3人チームに情シス得意マンが加わったことで、質的にもページ数的にも肉厚な技術同人誌を世に出せました。本誌は次の4章からなっています。

  • PowerShellによるWin32 APIプログラミングの基礎
  • 実践Metasploit API
  • Beyond Corp by Google
  • 相互連携する金融時代 - FAPI the Security

最初の2章はペネトレーションテスターに必須となる技術です。1章目は最近のExploitで多様されているPowerShellプログラミングの基礎です。ペネトレーションテスター向けに書かれていますが、情シスによる管理のコード化という観点からも非常に有用そうです。なお、この著者は1人で53p仕上げています。意味がわからない。怖い。

2章目はペネトレーションテスターなら一度は触ったことがあるであろうMetasploitのRPC APIの叩き方を取り上げています。Pythonクライアントを使って、効率的なペンテストをやりたいかたにはうってつけではないでしょうか。私はGolangで叩いて見ようと思いました。

そして、情シス待望の書が3章目です。みなさまの社内セキュリティはどのような環境でしょうか?USではネットワーク境界でセキュリティを担保しないゼロトラストネットワークスというアーキテクチャが主流になりつつあります。特にGoogleはそれに関する論文を「Beyond Corp」という名前で出すほど進んでおり、VPNに頼らない社内アクセスを実現しています。本章はその論文を日本語にまとめたものです。

最後の4章「相互連携する金融時代 - FAPI the Security」を私が執筆しました。まだ登場したばかりでその将来性は未知数ですが、いままで1サービス内に閉じていた金融系の経済圏をよりオープンにするにあたって策定されたFinancial API(FAPI)のRead Onlyなセキュリティ仕様を、OAuth 2.0やOIDCのrfcとともに読み解いたちょっと頑張ってしまった作品です。

この用に様々な、かつ尖ったセキュリティ技術の知識を結集させたものが、新刊「俺らの愛したセキュリティ」です。内容がわかったところで、次はどのように本著を作成から販売までしたかご説明します。

サークルとしての活動

メンバーに声をかけたのは大体1月です。しかし、私自身の転職やDroidKaigiでの講演により、本格的な方針を決定したのは2月中旬ぐらいでした。そこから各々が原稿をRe:Viewで書き、4/21にマージ・販促体制を構築し当日に臨みました。方針は次の通りです。

  • 電子書籍オンリー
  • ダウンロードカードによる配布
  • 1000円
  • 表紙担当を起用

電子書籍オンリーにしたのは、主に2つの理由があります。まだノウハウがないのに、期待値とことなる分量によって在庫リスクが発生することを恐れたを抱えたくなかったことが理由の1つです。もっと大きな理由は、ハードを準備することで圧迫されるスケジュールが大分厳しかった事です。正直、創業2年目のスタートアップに転職したてで、サークルのマネージメントに割く余力はなかったので、これはただしい判断だったと思います(そもそもマネージメント苦手です)。

ダウンロードカードを準備したのは、前回の反省からです。前回も電子書籍オンリーでしたが、QRコードを購入者に読み取ってもらう販促形式でした。これは意外と時間がかかります。それぞれのカメラの精度が異なりますし、混雑を極めている中でパラレルにさばくことは困難でした。何より①スマホを取り出す②アプリを立ち上げる③照準をあわせる④読み込む、とアクション数が多くなります。他にも、読み込んだあとなんらかの拍子にダウンロードをできなかった場合、支払った料金がむだになってしまうリスクがありました。

そういった反省から、1000円札と 交換する 形で入手できるダウンロードカードにし、これらの課題を解決しました。ただ、予想よりずっと来場者が多かったため、途中でダウンロードカードがなくなり、急いで擦りに行くという見通しの甘さを露呈してしまいました。次回のイベントに活かそうとおもいます。

また、前回は500円でしたが、今回は1000円にしました。これは価格そのものより、やはりオペレーションの観点からの改善です。基本的に1000円で支払う人が多い(という印象をもっている)技術書典で硬貨を使うと、お釣りが財布を物理的に圧迫します。

また、お釣りをわたすことはそれだけ価値交換のプロセスが多くなることだと思います。従って、人口密度の高いところではUX的に良くないと判断しました。技術書典はお祭りなので、出店から出店にすぐ移動できたほうが良い体験ではないでしょうか? そういった体験を考えた結果、一枚の交換券だけで欲しいものが手に入る方式にしてみました。こういった価格設定と先述した配布方法により、まあまあの体験を提供出来たかな、と思っています。

尚、公式から「後払い」アプリがリリースされていましたが、アプリ支払いと現金払いからみると、売上的には 2:8でした。後払いアプリもモダンではありますが、①スマホ取り出しからの④読み込み⑤それをサークルにみせて⑥サークルはそれを渡す、という手続きを踏まねばなりません。その点、現金は①千円を取り出す②渡す③サークルは本を渡す、とスピーディーです。したがって、しばらく現金前提で販売するのが良いな、と思いました(もちろん、後払いは引き続き利用)。

表紙担当としては、今回、正式にデザイナーさんに依頼をしました。まあ、現職の同僚なんですけど。サークルのコンセプトを伝えつつ、表紙のキャラをシャチにしたい、という良く分からない要望を、完全な形に落とし込んでくれました。ありがとうございます!お陰でサークル近くにおこしいただいた皆様が歩を止めて、興味を持ってくれるようになっていたと思います。

f:id:kengoscal:20180428022928p:plain

しかし、どちゃくそ格好よくないですか?シャチの可愛さとかっこよさが見事に共存していますね。青の濃淡をつかいわけることで、シャチが推進の浅いところへダイナミックに3D移動することを表現しているようです。他にも細かいセキュリティ関連のアイコンがキュートすぎます。凄い。すごすぎる。

最後に

もっと「このブースに寄ってよかったな〜」と思えるような体験を作ろうと思っています。具体的にはダウンロードカードをリッチにしたり、物理本を出すことです。先述の通りデザイナーさんに入ってもらうなど、一見して手にとりたくなるような体験を作って行くと同時に、セキュリティといえば「シャチ本」と誰もが思いつく世界にしていきたいと思います。

以上、今後とも宜しくお願いします。

P.S

  • 販売数は336部。前回は90部くらいでした。
  • シャチは私の趣味です。
  • Boothでのダウンロード販売に向けて動いています。

DroidKaigi2018で発表した内容の補足とスタッフとしての役割

DroidKaigi2018でスピーカーとして「認証と認可と君と」というタイトルで話してきました。

speakerdeck.com

また、併せて微力ながらもスタッフとしてお手伝いさせていただきました。

スピーカーとして

さて、技術的なところは今後ステップバイステップでコードともに説明していくと思うので、本稿ではエモいパート(序盤と終盤)のところのフォローをしようと思います。

序盤のエモい部分

序盤は何故、@ken5scalがこのテーマを攻めようと思ったかをFintechと業界絡めて話しています。 金融APIに求められるセキュリティ~APIDays Paris講演より|2017年2月号|金融ITフォーカス|刊行物|NRI Financial Solutions

上記の記事にある通り、Fintechという金融ビジネス上のイノベーションで、注力されようとしている分野は3つあると言われています。それが1) AI 2) Blockchain 3) オープンAPIです。その中でも特にオープンAPIに注目しています。企業単体ではできない・持てない価値を交換する窓口および経路として、シルクロードのような存在になると思っているからです。

そんなAPIを安全に守るため様々な対策が必要なのですが、そこで重要なのが認証と認可です。アクセス制御として第一の入り口となる認証・認可こそオープンAPI時代の要だと思い、今回のDroidKaigiのテーマとして取り上げさせて頂きました。

終盤のエモい部分

f:id:kengoscal:20180214020315p:plain

いくらOAuth2.0やFIDOを実装したところで、リスクから解放されることはありません。それぞれの仕様を安全たらしめているものがいつ危殆するかわからないからです。従って、目を光らせて最新の情報を追わなければなりませんが、既存の仕様を理解しつつ、常に最新を追うのは、これはなかなか骨です。そこで仲間が必要になるわけですが、なかなかセキュリティと開発が交わるチャンスは少ないです。願わくば、本セッションを通じて、すこしでも認証・認可について面白いと感じて頂いて、価値をユーザーに安全に提供するための仲間になっていただければ幸いです。

スタッフとして

相変わらず最高のチームでした。そんなチームですが、一端の中小企業の規模になりつつあり、参加者様も過去最多になりました。そのような状態で、どのように円滑・安全に運営していくかが、今後のワイの仕事になりそうです。 宜しくお願いします。

2017年を雑に振り返って、2018年の目標を雑に立てる

2017年振返り

1月

Android(Java)以外のプログラミングとして、初めてGoを弄り始める。自分ツールとして、GSuiteのコマンドラインツールをGoで作成。Slack Botも作成していたりしました。Reduxを勉強し始めている形跡があるが、正直ここらへんは自分のキャリアや人生に迷ってた間があります。後、副収入を得たのもここらへん。ちなみに、GSuiteツールキットは次のリポジトリ。正直ウンコだと思う。

github.com

2月

ちょびちょび前述のGSuiteのコマンドラインツールを作ってもいたけど、基本的にはDroidKaigiの準備をしていた模様。その過程で、使ってないActivityがあったら検知してくれるLintを作ったりしました。更新できてない... github.com

3月

DroidKaigiで「ドキッ★脆弱性 onCreate() から onDestroy() まで」発表。会社のアプリに脆弱性の報告をされたので、原因や対応フローといったのをコミュニティ内でシェア。Webアプリ(Railsエンジニア)の人と一緒にDockerデビュー。実はこのタイミングで、CISOの椅子を用意してくれていたスタートアップに転職しようとしていた。何やかんやあって、半年待ってもらうことに(結局、今の会社に残ったけど)

ドキッ★脆弱性 onCreate() から onDestroy() まで // Speaker Deck

4月

基本的に会社のことしかしてなかった。死ぬほど忙しかった。会社でWindowsサーバー・ドメコン・グループポリシーの権限部分でウンウン唸ってた。Twitterのタイムラインみると3am~4amまで仕事してた模様。引くわ〜。社長への報告とかもここから始まったかも。会社の全体的なセキュリティ方針とかお願いする予算とかも弾いてて、結構プレッシャー大きかった。ポッドキャスト「セキュリティのアレ」に準レギュみたいなポジションから参加したのも、ここらへんから。

5月

仕事については、大体4月と同じ。休日はTerraformをちょろっといじったりしてた。また、自分でコマンドラインを作ったりした結果、「もっとちゃんとプログラムの基礎やんないとなー」と思い立ってたのはここらへん。Googleが学生向けの技術開発者キャリアでやっておくべきことをリストしておいたので、そのチェックリストを作る。

github.com

6月

上記のを見て、暗号に関する授業をCourseraで修了。Andrew NG教授のMachine Learningもなんだかんだで終わってなかったの修了。両方ともCertificateは貰った。ただ、暗号の授業は面白かったけど、何となく思ってたのと違った。僕がのぞんでたのは、結城先生の「暗号技術入門」& 実装だったんだけど、Courseraは暗号が安全であるための数学的要件や攻撃方法がメインだった。なので「Javaで作って学ぶ暗号技術 - RSA,AES,SHAの基礎からSSLまで」を参考にして、Goを使った実装をしている。RSAとAESまでできたけど、SHAからSSLまでは出来てない。やるかは...わからない。色々やりたいことがあるので。あと、地味にGCP, コンテナ, k8sを使ったサイトを1つリリースしてた。更新は手動。

github.com

http://amzn.asia/crpzzCh

7月

仕事は相変わらず死んでたけど、技術的なことというより、非技術的な調整をしまくってて忙しかった。エンジニア is 何、セキュリティ is 何と超自問自答してた時期。 前述の暗号 in Goを実装しているときに、Techboosterのmhidakaさんにテクブで声をかけられる(もともとDroidKaigiで知り合いであった)。2つ返事でおkしたのが運の尽き。 ひーこらいいながら、AndroidのSMS Verifier APIについての初原稿を仕上げる。次のリンクから買えるで。

techbooster.org

あわせて、ssmjpで話してほしいといわれたので、やはり何も考えずに受けて、ひーこらいってた。NISTからDigital Identity Guide (SP800-63)がでたので、そのSMS認証について話す。これを日本語で不特定多数の前で話したのは、僕が初めて...かも...?

俺のSMS認証がこんなに非推奨なわけがない // Speaker Deck

GoogleのSecurity Princessと呼ばれる方が書いたセキュリティを専門にするひとの心得、というのを日本語訳した。これが結構バズった。そしてビビった。

ken5scal.hatenablog.com

8月

仕事は相変わらず(略。で、プログラミングしなさすぎてヤバイな、と思ったので、隙間時間で会社で使ってるサービスのAPIを叩くクライアントアプリを作成。コマンドラインも作っておいた。ビルドは手動でmakeファイルさえ作ってない。地味にAWSを始める(インスタンス立てるだけじゃなく、組織の中でちゃんと使う)。SlackのChat Botもここら辺でデビュー

github.com

9月

ソフトウェア的な活動は特にせず。お仕事は一旦落ち着く。ちょっとダレる。夏休みとしてエストニアに旅行にいく。 e-govショールーム、Funderbeam、Transferwise、Verif、Cybernetica、SK IDソリューション、エストニア情報センター(RIA)に訪問したりしていた。終わった後に、自分が所謂「日本企業の視察・情報収集」しかしてないことに気づき、激しく自己嫌悪。いや、日本のFintech事情とか話したけど、貰った情報の価値からしたらちょっと...。尚、ご飯は口に合わなかった模様。歴史的にはものすごい面白く、なぜエストニアが現在のエストニアになったかが理解できた。そして、その歴史的背景無視して日本が真似してもしゃーないのでは、というスタンスになった。そんな間に会社が上場。

10月

GCP, k8sでのインフラ構築2サイト目を構築開始。技術書典3に「ニッチ・セキュリティ」サークルから「現時点で日本語でググっても出てきにくいセキュリティ技術」を出す。自分はUAF 1.1に書いたが、一緒に参加頂いたbbr_bbqさんと北原さんの記事のクオリティの高さに完全降伏した。幸い好評のうち終了。

techbookfest.org

11月

GCP, k8sでのインフラ構築2サイト目の構築終了。色々あって神経をすり減らす。

12月

上記のサイトでバックエンドサーバーが必要になったので、gRPCデビュー。サーバー側はGoで、クライアント側はRubyで書いた。再度、mhidakaさんに誘われて、テクブ本を書く。今回のテーマはFirebaseを使った認証。何だかんだ言ってKotlinまだ触ってなかったので、全てKotlinで書く。

techbooster.org

ふりかえると

色々やってるな〜(小並 (´ε`;)ウーン…振り返ると殆ど仕事しかしてない気配です。何度か精神やばいな、っておもったことあるんで、ちゃんと休みはとろう。 今年の目標はQoLを上げるのも含めておいたいと思います。

で、これが去年の目標なわけだが、CISSP/機械学習/サービス作成というのができてませんな。 http://ken5scal.hatenablog.com/?page=1483260359

筋トレにあまりいけなくなっている事実は見過ごし難い。

そしてCNCFとの出会いや4月からの仕事で、完全に趣向が変わってきてはいる。

ブロックチェーンの流行りなど、新しい技術を眺めているだけでいいのだろうか。

CISSPとらなかったなあ

2018年の目標

やりたいことは沢山あるが、やはり基礎と認証・認可を固めて行こうと思う。また、攻撃技術は身に着けないとだめそう。コマンドライン自分で作ったけど、テストないと厳しい。QOLをあげるために、規則正しい生活を。

絶対やる

時間があったら

  • サービス作り。「Go Web Programming」
  • CISSP, CISA?
  • 「Real HTTP World」
  • 機械学習 -> 原点に立ち返って考えると、わいは異常検知をやりたかっただけなんや...個人的に数冊本読んで、kaggleに手をだす?
  • ブロックチェーン -> とりあえずフォロワーレベルでいいかな。本職はセキュリティで、いまだユースケースの確定してないところに本腰いれてつっこんでも迷子になるだけそう。入門書を数冊読んで、下を真似するぐらいで、今はいいかも。 Building Blockchain in Go. Part 1: Basic Prototype · Going the distance

Androidアドベンドカレンダー、Firebase Authenticationで電話認証する #Android #Authentication

Android アドベントカレンダー 20日目の記事です。

qiita.com

とある同人誌に掲載する予定だったのですが、風邪でぶっ倒れて書けなかった最終章をこちらに書きます。 内容は、Firebase Authenticationを使った電話認証のあれこれです。以降、「Firebase Authenticationの電話認証」を電話認証として略させて頂きます。 また、本稿ではFirebaseの仕組み上、みんなだいすき2要素認証ではなく2段階認証と呼称させていただきます。 詳しくはこちらをご覧ください。

blogs.manageengine.jp

本稿は次の内容でお送りします。 - ベーシックな電話認証 - 既存アカウントとのヒモ付け - 電話認証を使ったなんちゃって2段階認証 - SMS Retriever APIを使った半自動2段階認証

では、やってまいりましょう。

ベーシックな電話認証

いきなりで申し訳ないのですが、電話認証を実装したアプリはエミュレータ上では実行できません。いや、実行はできますが、電話認証周りの機能は動きません。クラッシュとかではなく単純に動きません。実機をご用意ください。

まずは電話番号をFirebaseに登録する必要があります。その場合、1) その電話番号が本当に実在するものか、2) 登録要求をリクエストしたユーザーのものであるか確認をとる必要があります。コードでお話すると、まず PhoneAuthProvider.getInstance().verifyPhoneNumber で電話番号の存在を確認し、そして、その後SMS経由で送られた確認コードをユーザーから受理・検証することで、登録要求リクエストの真正性を確認します。

1) はFirebaseの PhoneAuthProcider.getInstance().verifyPhoneNumber を使って出来ます。

   // 該当の電話番号に確認コードを送った結果を受け取るコールバック
        mCallbacks = object : PhoneAuthProvider.OnVerificationStateChangedCallbacks() {
            // 後でつかいます
            override fun onVerificationCompleted(p0: PhoneAuthCredential?) {
                Toast.makeText(this@EmailPasswordActivity, ": Verification Completed", Toast.LENGTH_SHORT).show()
            }

            // 後でつかいます
            override fun onVerificationFailed(p0: FirebaseException?) {
                Toast.makeText(this@EmailPasswordActivity, p0?.message, Toast.LENGTH_SHORT).show()
            }

            override fun onCodeSent(p0: String?, p1: PhoneAuthProvider.ForceResendingToken?) {
                mSMSVerificationID = p0.toString()
            }

            override fun onCodeAutoRetrievalTimeOut(p0: String?) {
                mSMSVerificationID = p0.toString()
            }
        }


    private fun registerPhoneNumber(phoneNumber: String) {
        PhoneAuthProvider.getInstance().verifyPhoneNumber(
                phoneNumber, // E.164フォーマットである必要があります。このフォーマットは[+][国コード][エリアコード]になります。例えば080-1234-5678が電話番号なら、E.164フォーマットで+818012345678です。
                10, // 10秒でタイムアウトする
                TimeUnit.SECONDS,
                this@EmailPasswordActivity,
                mCallbacks
        )
    }

2) は真正性確認になります。ユーザーが取得した確認コードとmCallback内で取得したSMS確認IDを組合せてたクレデンシャルがまずは作成されます。アプリはそれをサーバーに送信し、サーバーはそれを検証します。

val auth = FirebaseAuth.getInstance()
val credential = PhoneAuthProvider.getCredential(mSMSVerificationID, verificationCode)
auth.signInWithCredential(credential).addOnCompleteListener { task ->
    if (task.isSuccessful) {
        auth.currentUser?.let { updateResult(it) }
    } else {
        Log.w("Phone", "signInWithPhoneAuthCredential:failure", task.exception)
        Toast.makeText(this, "Authentication failed.", Toast.LENGTH_SHORT).show()
    }
}

タスクが成功した場合、その時点で電話認証をしたユーザーはFirebaseに登録されていることになります。次の画像をご参照ください。

f:id:kengoscal:20171217011643p:plain

とてもハンディですね。

既存アカウントとのヒモ付け

でも、これでは既存アカウントに紐付いてません。単純に、新しい別のアカウントが生成されただけです。既存アカウントに紐付かせるために、電話認証で登録したアカウントを削除したうえで紐付かせたいアカウントにリンクさせてみましょう。下記の様にログイン済みのユーザーにクレデンシャル(SMS確認IDとSMSに送られた確認コード)をリンクさせればおkです実装すればおkです。

val auth = FirebaseAuth.getInstance()
val smsCredential = PhoneAuthProvider.getCredential(mSMSVerificationID, findViewById<TextView>(R.id.mfa_code).text.toString())
auth.currentUser?.linkWithCredential(smsCredential)?.addOnCompleteListener { task -> // auth.currentUserはFirebase Authenticationですでにサインインしているホスト
     if (task.isSuccessful) {
          mAuth.currentUser?.let { updateResult(it) }
     } else {
          Toast.makeText(this, task.exception?.message, Toast.LENGTH_LONG).show()
     }
}

ひも付きました。

f:id:kengoscal:20171217015652p:plain

次は2段階認証の話になります。

電話認証を使ったなんちゃって2段階認証

上記の通り、複数の認証プロバイダ(メールアドレス、電話番号)を1つのアカウントに紐付けることができました。そこでメアドとSMSを使った2段階認証を設定してみたいと思います。 注意: 今のFirebaseの仕組み上、メアド・パスワードの認証が成功した時点でサインインした状態になってしまいます。従って、一度サインアウトして更に電話認証する流れになります。なので、本章はなんちゃってとなっています。

流れとしては、signInWithEmailAndPasswordでサインインしたユーザーの情報から電話番号を取得し、確認コードを送ります。これはFirebaseのContinuationインターフェースを使って実現できます。ContinuationインターフェースではTaskの結果を受取り、任意の処理を実行・出力する実装ができます。

// 認証結果を元に、電話番号へ確認コードを送る
class Send2FAVerificationCodeToSMS(
        private val executor: Executor,
        private val callback: PhoneAuthProvider.OnVerificationStateChangedCallbacks) : Continuation<AuthResult, Unit> {
     override fun then(task: Task<AuthResult>) {
         if (!task.isSuccessful || task.result.user.phoneNumber.isNullOrEmpty()) {
             return
         }
         return PhoneAuthProvider.getInstance().verifyPhoneNumber(
                task.result.user.phoneNumber.toString(), // Needs to be E.164 format. eg. +81805541xxxx(Japan), [+][country code][subscribed number with area code]
                10,
                TimeUnit.SECONDS,
                executor,
                callback
        )
    }
}

// 何となく別スレッドで処理したかった
class ThreadPerTaskExecutor : Executor {
    override fun execute(r: Runnable) {
        Thread(r).start()
    }
}

// 上記をsignInWithEmailAndPasswordのタスク終了後に実行する
mAuth.signInWithEmailAndPassword(email, password)                    
                .continueWith(Send2FAVerificationCodeToSMS(ThreadPerTaskExecutor(), mCallbacks))
                .addOnCompleteListener { task ->
                    signOut() //signInWithEmailAndPasswordが成功した時点で、サインイン済みになってしまっているのでサインアウトを実施
                    if (!task.isSuccessful) {
                        Toast.makeText(this, task.exception?.message, Toast.LENGTH_LONG).show()
                        return@addOnCompleteListener
                    } else {
                        Toast.makeText(this, "Verification Code has been sent", Toast.LENGTH_LONG).show() 
                    }
                }

手元の携帯電話に確認コードが送られてきました。前章で紹介したとおり、このコードと確認IDを組合せたクレデンシャルを引数にするsignInWithCredential を呼び出せば、メールアドレス認証と電話認証を組合せた2段階認証の出来上がりです。

SMS Retriever APIを使った半自動2SV認証

ところで皆さん、2SVするとき電話番号入力するのめんどくさくありませんか?次のような手順を見て頂ければ、半分くらいのかたには同意頂けるかと思います。

  1. 自分の電話番号を入力
  2. サーバからの認証コードを待つ
  3. SMSまたは電話アプリを立ち上げる
  4. 認証コードを入力

このステップ2からステップ4までを自動化してくれる仕組み、それがGoogleがだしているSMS Retriever APIです。 当該APIを使うことで、サーバからSMSを受け取ったAndroid端末(のGoogle Play Service)がブロードキャストし、特定のアプリがそれを受信・SMSをパースできるようになります。 パースさえできれば、その後処理でサーバに認証コードを送るだけなので、ユーザー体験を損なわない自動的な2段階認証を提供できるわけです。

以下、実装を軽くみていきます。 注意: なお、筆者はスマホ(SIM Free機)と電話を分けて運用しているので、本章は動作確認できていません。

SMS Retriever APIの呼び出し

SmsRetrieverClient インスタンスを生成し、startSmsRetriever()を呼びます 立ち上がったAPIもといタスクは認証コードを含んだSMSが届くのを待ちます。5分立つとタイムアウトしますが、待ち時間は変更できます。

class PhoneNumberVerifier : Service() {

    private var smsRetrieverClient: SmsRetrieverClient? = null

    override fun onCreate() {
        smsRetrieverClient = SmsRetriever.getClient(this)
    }

    // このサービスは `PhoneAuthProvider.getInstance().verifyPhoneNumber` の実行直後に呼び出される
    override fun onStartCommand(intent: Intent, flags: Int, startId: Int): Int {
        super.onStartCommand(intent, flags, startId)

        val action = intent.action
        if (ACTION_VERIFY == action) {
            val task = smsRetrieverClient!!.startSmsRetriever()
            task.addOnCompleteListener {task ->
                if (task.isSuccessful) {
                     // 何か. smsRetriever開始成功のお知らせ
                } else {
                     // 何か. smsRetriever開始失敗
                }
            }
}

SMSから認証コードの取り出し

認証コードが端末に届いた際、Google Playサービスが、SmsRetriever.SMS_RETRIEVED_ACTIONを指定した明示的なブロードキャストを発信します。このブロードキャスト内に認証メッセージが届くわけです。従って、アプリ内ではBroadcastReceiverで本メッセージを抽出します。

class SmsBrReceiver : BroadcastReceiver() {

        override fun onReceive(context: Context, intent: Intent?) {
            if (intent == null) {
                return
            }

            if (SmsRetriever.SMS_RETRIEVED_ACTION == intent.action) {
                val extras = intent.extras
                val status = extras!!.get(SmsRetriever.EXTRA_STATUS) as Status
                when (status.statusCode) {
                    CommonStatusCodes.SUCCESS -> {
                        val smsMessage = extras.get(SmsRetriever.EXTRA_SMS_MESSAGE) as String
                        Log.d(TAG, "Retrieved sms code: " + smsMessage)
                    }
                    CommonStatusCodes.TIMEOUT -> doTimeout()
                    else -> {
                    }
                }
            }
        }
}

ここで取得したsmsMessage = 確認コードを、前述のsignInWithCredentialにいれてFirebaseに送信することで、半自動2SVが完了します。

//mSMSVerificationIDはPhoneAuthProvider.OnVerificationStateChangedCallbacks()のonCodeSentから取得
val credential = PhoneAuthProvider.getCredential(mSMSVerificationID, code) 
mAuth.signInWithCredential(credential)

以上です。

終わりに

以上で、Firebase Authenticationの電話認証周りの紹介をさせていただきました。認証システムは設定するには非常に多くの考慮が必要ですので、Firebase Authenticationを利用すれば、ベストではないにせよ2段階認証までハンディに実装できるようになります。