技術めいた何か

1人の学生によるIT系の記事群

Challenge CVE-2020-13777に応募しました!

はじめに

編集履歴:

  • 2020/07/03 18:23: 誤字脱字の修正
  • 2020/07/03 13:25: 初版公開

本記事及び、企画「Challenge CVE-2020-13777」へ提供した解説文章・PoCは情報通信産業に関わる人の情報セキュリティのリテラシーの向上に貢献することを目的としています。 修正パッチが広く配布されている脆弱性であるCVE-2020-13777について、修正パッチ配布後に開発元によって公開された脆弱性の情報を元に技術的な検証を行った結果を啓蒙活動の一環として公開しています。 それにより、脆弱性について情報通信産業に関わる人に広く認知されることを期待しています。

なお、作成し公開したPoCは技術的な検証を目的に作成されたもので、実在のサーバーに対してCVE-2020-13777を用いた攻撃する能力は無く、また攻撃を意図して作成したものではありません。 このPoCは主催者が配布・解析を許可したパケット情報をまとめたファイル(pcapファイル)を解析するように設計しており、外部のサーバーとの通信は一切行わずオフラインで動作します。

こんにちは、@prprhytです。 先日開催されたChallenge CVE-2020-13777に応募しました。
Challenge CVE-2020-13777は、Ohtsuさん(@jovi0608)が主催する 先日情報が公開されたGnuTLSの脆弱性であるCVE-2020-13777についてTLS1.3に関係する部分の解説とPoCの公募をする企画です。

企画の詳細や結果の詳細についてはOhtsuさんのブログを参照してください。

告知・募集:
https://jovi0608.hatenablog.com/entry/2020/06/13/104905

Ohtsuさんのフォローブログ(結果と提出した解答へのフォロー):

jovi0608.hatenablog.com

解答:

https://gist.github.com/prprhyt/548ba3148f3b1bbfa5c20edde60d6b75

PoCのソースコード:

github.com

選考の結果提出課題を高く評価していただきまして、嬉しいことに主催者であるOhtsuさんからの正解賞(Amazonギフト1万円)と協賛のVさん(@voluntas)からVさん賞(Amazonギフト3万円とお好きなラムダノート本1冊)を頂きました。改めてありがとうございます。 特に、Vさんからは告知にあった額面より大幅にブーストしていただいた上、好きなラムダノート本として「プロフェッショナル SSL/TLS」をいただきました! 改めて、企画していただいたOhtsuさんと協賛のVさんにこの場を借りてお礼を申し上げます。 (あと、自分で言うのは少し恥ずかしいですが気合を入れて解説を書いたおかげかお2人からお褒めの言葉をいただきました。)

応募にあたって課題の進め方

注意: 以降の文章はOhtsuさんのフォローブログを読んでいる前提で書いています。 よって、セッション再開時の認証の説明など技術的な解説の多くは省略してあります。予めご了承ください。

CVE-2020-13777のTLS1.3に関係する部分の解説とPoCについての詳細はOhtsuさんのフォローブログを見ていただくとして、ここでは問題2を例に実際に手をどう動かして課題を進めたかについて共有しようと思います。 ただし、僕は課題への対処の仕方は十人十色だと思っていて課題の進め方に正解があるとは思っていません。 なのでこういうやり方もあるのだな、くらいに思ってもらえると幸いです。

公募の問題は次の通りです。

以下のレポジトリにある pcap データを使って次の問題1,2に回答してください。
pcap データにはGnuTLS-3.6.13のサーバ(192.168.100.23:5556)に対するTLS1.3の接続データが2つ含まれています。1回目は新規TLS1.3接続、続く2回目は 0-RTT のTLS1.3再接続です。

https://github.com/shigeki/challenge_CVE-2020-13777 1. pcap中のTLS1.3 ClientHelloデータだけ使って、CVE-2020-13777によってTLS1.3のMITMが可能であることを証明してください。
2. pcap中の暗号化されたTLS1.3 の 0-RTTアプリケーションデータをCVE-2020-13777によって復号し、アプリケーションデータの平文を取得してください。

引用: https://jovi0608.hatenablog.com/entry/2020/06/13/104905

さて、本題ですが僕は課題2を次の手順で進めました。

  1. CVE-2020-13777のIssueに上がっている動作を再現できる環境の構築
  2. 配布されたpcapを眺める
  3. ドキュメントとプログラムの調査とメモの作成
  4. PoCの実装
  5. PoCの実装で行き詰まった箇所があれば2や3に戻る

また、調査やPoCの実装に使用したツールは次の通りです。

  • Wireshark: 配布されたpcapを眺めるのに使用
  • ブラウザ・Google: RFCを読んだり参考になりそうな情報の検索をするのに利用
  • テキストエディタ: メモ用
  • Python3.7: PoCの実装に使用

なお、課題開始時点でのTLS1.3に関する知識は次のとおりでした。

  • おおまかな特徴やTLS1.3の暗号理論における安全性についての記事を読んだことがある。
    また、TLS1.3への攻撃の一部について概要を知っている。
  • プロトコル的な観点についてはなんとなくTLS1.2までとTLS1.3の違いを知っているが詳細は知らない
    • フルハンドシェイクが2-RTT->1-RTTになった。条件を満たせば0-RTTハンドシェイクが使えるとか。上記の記事にある概要は知っているくらい。
    • 0-RTT時の認証についてはあまり詳しくない。
    • 完全に忘れていたのですが、TLS1.3のPSKやセッション再開について2年前にセキュリティ・キャンプ全国大会2018 TLS1.3/暗号ゼミの応募課題のために少し調べていたことがわかりました。ただし、このときは理解できていなかった(この記事を書いている最中に当時の応募用紙を見直したらかなり間違いがあったので)

では、次の節から手順ごとにやったことを説明します。

ちなみに余談ですが、問題1については次のように進めました。

  1. PSK(Pre-shared key)をセッション再開に用いるという情報をもとにMITMのシーケンス図の下書きをする
    (参照: RFC 8446 Section 2.2: https://tools.ietf.org/html/rfc8446#section-2.2)
  2. 問題2を解いてPSKの導出やkey schedulingついて理解をする
  3. 下書きをと問題2を解く過程で得た情報をもとに提出用の解説を書く

1. CVE-2020-13777のIssueに上がっている動作を再現できる環境の構築

GnuTLSのGitLab上のCVE-2020-13777に関するIssueを見ながら報告されている動作を再現できる環境を構築します。 該当のIssue: https://gitlab.com/gnutls/gnutls/-/issues/1011
以下の環境を構築しました。

インストールするものは次の通りです。

  • GnuTLS 3.6.13
  • OpenSSL 1.1.1g (21 Apr 2020)

GnuTLSのバイナリを入手する方法はソースコードからのビルドや各パッケージマネージャーから入手するなどがあります。 各OSやディストリビューションによって手順が異なるので手順は割愛します。

2. 配布されたpcapをながめる

TLS1.3の仕様であるRFC 8446の2.2節によるとセッション再開に用いる情報であるPre-Shared Keyはセッション再開時のCHLOに含まれるようです。つまり、セッション再開時のCHLOのどこかにPSKに関する情報が含まれているはずです。
参照: RFC 8446 Section 2.2: https://tools.ietf.org/html/rfc8446#section-2.2

その情報を頭に入れた状態で、Wiresharkで配布されたpcapファイルを眺めました。 1つめのClient Hello(CHLO)をみてもセッション再開に関係しそうな情報は特になさそうです。 2つめのCHLOを見ます。すると、画像のようにPSK Identity->Identityの先頭の16byteが0になっているのに気づきます。 怪しいですよね。

cve-2020-13777-resumption
図:配布されたpcapファイルの再開時のCHLOの中身

ここで正常なセッション再開のCHLOパケットを見てみます。 正常なセッション再開のCHLOパケットは修正済みのGnuTLSサーバー(ver 3.6.14以降)でGnuTLSの該当IssueStep to Reproduceの手順を参考に同じサーバーに対してセッション再開をすることで入手できます。 なお、逆に3.6.13以下で手順通りに実行するとCVE-2020-13777の認証バイパスが再現します。

nomal-resumption
図:正常な再開時のCHLOの中身

正常なCHLOを見ると先頭16byteが0になっているわけではありません。 では、手元でCVE-2020-13777の認証バイパスを再現した場合のセッション再開時のCHLOはどうでしょうか。次に画像を示します。

cve-2020-13777-resumption
図:手元でCVE-2020-13777を再現したセッション再開時のCHLOの中身

確認すると、配布されたpcapのセッション再開時のCHLOパケットと同じように先頭16byteが0になっていることがわかります。

3. ドキュメントとプログラムの調査とメモの作成

ここで、おもむろにGnuTLSの暗号化されたセションチケットの書式を確認します。 20200613055805
図:GnuTLSのチケット書式

図の引用元: https://jovi0608.hatenablog.com/entry/2020/06/13/104905

図の左側のテーブルの一番上の項目を見てください。 Key Name(16bytes)となっています。 これらの情報から次の仮説を立てます。

  1. 暗号化されたセッションチケットはセッション再開時のPSK Identityに含まれている。
  2. そして、セッションチケットの暗号化/復号鍵は構造体で定義されており、それがall-0で初期化されるため、Key name(16bytes)や暗号化のkey, MACのkeyも0になっている。

この仮説に基づいて調査をします。 セッションチケットを復号できたとすると、攻撃者が入手できるのは図:GnuTLSのチケット書式の右側のテーブルにあるGnuTLSのチケットデータの中身の書式にある情報です。

順番に項目を見てresumption_master_secretnonceがあるのが気になりました。名前からして秘密情報にあたりそうです。ここで、resumption_master_secretnonceが何に使われているのかRFC 8446から確認します。 次の式を見ます。

psk=HKDF-Expand-Label(resumption_master_secret,
                        "resumption", nonce, Hash.length)

参考:RFC8446 4.6.1 https://tools.ietf.org/html/rfc8446#page-75 を基に作成

Ohtsuさんフォローブログを読んだ方はもうおわかりだと思いますが、この式から、resumption_master_secretnonceはセッション再開時の認証や各暗号化鍵/復号鍵の鍵導出に使うPSKの導出に使用されていることがわかりました。

次にPSKからの鍵導出についてTLS1.3のKey Schedulingの図を確認します。

Screen Shot 2020-06-17 at 18 05 36
図:TLS1.3のKey Scheduling

図の引用元: RFC8446 7.1 https://tools.ietf.org/html/rfc8446#page-93

これで、PSKからどのようにPSKから各暗号化鍵/復号鍵を導出しているかわかりました。

また、RFC 8446 section 7.3より、この図の中で0-RTT Application dataの暗号化/復号鍵, ivの基となる情報に該当するのは client_early_traffic_secretであることがわかりました。

参照:RFC 8446 section 7.3 https://tools.ietf.org/html/rfc8446#section-7.3

次の節ではこの節まででわかった情報をもとに配布されたpcap中の0-RTT Application dataを復号するPoCの実装をしていきます。

4. PoCの実装

PoCの実装に入りました。 さて、3節で次のように仮定しました。

  1. 暗号化されたセッションチケットはセッション再開時のPSK Identityに含まれている。
  2. そして、セッションチケットの暗号化/復号鍵は構造体で定義されており、それがall-0で初期化されるため、Key name(16bytes)や暗号化のkey, MACのkeyも0になっている。

この仮定にもとづいて実装を進めました。(そして、結果的にこの仮定は正しかったです)
なお、実装時もわからない箇所が出たら繰り返し調査をする方針で進めました。

0-RTT Application dataの復号までの流れは次のとおりです。

  1. 暗号化されたセッションチケットの復号, MACの検証
  2. セッションチケットに含まれるresumption_master_secretとnonceからPSKを導出
  3. TLS 1.3のKey Schedulingに従ってclient_early_traffic_secureを導出
  4. client_early_traffic_secureから0-RTT Application dataの復号鍵とivを導出し、ivからnonceを導出
  5. 0-RTT Application dataを復号, MACの検証

詳細はOhtsuさんのフォローブログやPoCのソースコードを参照してください。 なお、ソースコード中には各処理についてコメントしてあります。

以下にPoCで各処理を実装する上で特筆すべき点や再度調査を行ったものについて書きました。 主に実装依存のもので、RFC 8446に定義されていないもの中心です。 なお、ソースコードの検索についてはgitlabの検索+ローカルにgit cloneした上で、git grepでやっていました。

1. 暗号化されたセッションチケットの復号, MACの検証 のMACの計算手順

セッションチケットが実装依存であり、確認した範囲ではRFC 8446に具体的な記載がなかったのでMACの算出方法についてはGnuTLSの実装を参照しました。 次の手順で各値を入力することで比較用のMACを計算できます。 GnuTLSの実装を見たところ、ちゃんとEncrypt-then-MACのようです。

  1. HMACでハッシュ関数SHA1(図:GnuTLSのチケット書式より)に指定する
  2. HMACの鍵を入力(all-0で16byte)
  3. セッションチケットのKey Nameを入力
  4. セッションチケットのIVを入力
  5. セッションチケットのdata length(暗号化部分の長さ)
  6. セッションチケットdata(暗号化された状態のデータ)を入力
  7. MACを計算する

参考: https://gitlab.com/gnutls/gnutls/-/blob/1d4615aa650dad1c01452d46396c0307304b0245/lib/ext/session_ticket.c#L155

余談ですが、GnuTLSでのセッションチケット復号時のMACの計算関数の呼び出し箇所を見ると ダイジェストを受け取る変数名がcmacとなっており、そのせいで最初見たときはMACの方式がCMACなのかと勘違いしかけました。ハッシュ関数の指定があるのでCMACだとおかしいと思いながらコードを読み進めてHMACだと確認しました。 (おそらくcalculated MACの略のつもりなのでしょうが紛らわしかったです...)

2以降で使用するHKDFのハッシュ関数の決定方法

HKDFで使用するハッシュ関数の指定方法について確認をしたところ、GnuTLSでは図:GnuTLSのチケット書式の右側GnuTLSのチケットデータの中身の書式の先頭2byteのprf_idが該当することがわかりました。

参照: https://gitlab.com/gnutls/gnutls/-/blob/d00638997fa269a975095d852633b48b2b64fbf9/lib/ext/pre_shared_key.c#L53

なお、上記のリンク先で呼び出している_tls13_expand_secret2RFC 8446でいうとHKDF-Expand-Label()にあたります。

参照: https://gitlab.com/gnutls/gnutls/-/blob/d00638997fa269a975095d852633b48b2b64fbf9/lib/secrets.c#L122

そして、配布されたpcapの再開時のCHLOではprf_idは7(10進数)です。 prf_id==7の場合の対応するハッシュ関数を調べたところ、定数GNUTLS_MAC_SHA384に7が割り当てられていることがわかりました。 そして、定数名からprf_id==7に対応するハッシュ関数はSHA384であることがわかりました。

なお、調査手順は次のとおりでした

  1. ciphersuiteが定義されていそうなソースファイル(lib/algorithms/ciphersuites.c)をみてみる
  2. ハッシュ関数に関するものもいくつか参照されていることがわかった
  3. 試しにgit grep GNUTLS_MAC_SHA256 する
  4. gnutls/devel/libdane-latest-x86_64.abi が検索にかかり、具体的な値を紐付けていそうなので確認する
  5. 7に該当するのがGNUTLS_MAC_SHA384だとわかる

参照:
lib/algorithms/ciphersuites.c: https://gitlab.com/gnutls/gnutls/-/blob/e48290a51da19288986bd7aaca265ea62b054dc8/lib/algorithms/ciphersuites.c#L407
gnutls/devel/libdane-latest-x86_64.abi: https://gitlab.com/gnutls/gnutls/-/blob/e48290a51da19288986bd7aaca265ea62b054dc8/devel/libdane-latest-x86_64.abi#L304

4. TLS 1.3のKey Schedulingに従ってclient_early_traffic_secureを導出

当初、うまくclient_early_traffic_secureが算出できなかったのですが、 以下のような誤りをしていたのが原因でした。

client_early_traffic_secure = Derive-Secret(Early Secret, "c e traffic", ClientHello)

とすべきところを以下のようにしていました。

client_early_traffic_secure = Derive-Secret(Early Secret, "c e traffic", "")

Key Schedulingの図を見直すことで解決しました。

5. 0-RTT Application dataを復号, MACの検証

AEADのAssociated(additional_data)の計算方法
0-RTT Application dataの暗号化には1つ前のセッションのCipher Suiteが選択されます。 そして、1つ前のCHLOを見ると先頭にCipher SuiteのTLS_AES_256_GCM_SHA384(0x1302)が選択されていました。 そのことから、AES_256_GCMで暗号化されていて、MACの計算にはSHA384が使用されていると仮定しました。

そして、AEADの暗号化/復号に必要なAssociated(additional data)の算出方法は次の通りです。

additional_data = TLSCiphertext.opaque_type ||
                        TLSCiphertext.legacy_record_version ||
                        TLSCiphertext.length

参照: https://tools.ietf.org/html/rfc8446#page-81

よって、AEADのassociate=(Early dataが入っているTLSレコードレイヤーのヘッダ+暗号文の長さ) であることがわかりました。

PoCの実装・調査の記録については以上です。 余談ですが、実行結果は次の通りです(ASCII, HEX)。

python3 main.py
b"Let's study TLS with Professional SSL/TLS!\n\n\x17"
4c6574277320737475647920544c5320776974682050726f66657373696f6e616c2053534c2f544c53210a0a17

実はお好きなラムダノート本にProfessional SSL/TLSを選んだ理由の1つはこれです。 (もう一つの理由は読んだことがなかったからです。あと評判が良いので。)

最後に

TLS1.3の再接続性まわり、特に0-RTT周りは課題に取り組む前は雰囲気でしかわかっていなかったのですが、この機会に楽しく理解を深めることができました。 改めまして、企画を主催していただいたOhtsuさん(@jovi0608)、協賛のVさん(@voluntas)にお礼を申し上げます。 今後ですが、OhtsuさんからプロフェッショナルSSL/TLSの書評をお願いされたので、時間を見つけて読み進めようと思います。(今年は修論もあるので纏まった時間をとるのが難しいかもですが...) また、Vさんからは頂いた賞金で経済を回すように言われたので経済を回していくぞ〜という気持ちです。 やっていくぞ💪

SECCON Beginners CTF 2020 Writeup(Crypto: R&B, RSA Calc)

2020/05/23 〜 2020/05/24に開催されたSECCON Beginners CTF 2020にTeam: r0bu5tのCrypto問担当(?)として参加しました。prprhytです。 せっかくのアウトプットする機会なので、手をつけた分は復習も兼ねてWriteupを書きます。

僕自身は解いたのは2問だったのですが、チームメンバーのおかげで順位は44thでした。 反省点も多いので貢献できるように精進します。。 f:id:atofaer:20200524153614p:plain

Writeup

crypto: R&B

与えられたもの

与えられなかったもの

  • FORMAT(後述)

符号化されたFlagと符号化を行った際に使われたらしいソースコードが渡されます。 ソースコードを読むと FORMATという文字列に従って、rot13とBase64で符号化するようでした。 例えばFORMAT='BRBB'の時はBase64->rot13->Base64->Base64と符号化するプログラムのようでした。 厳密には符号化したあとにBase64で符号化した場合はB、rot13で符号化したときにはRが符号化後のFLAGの先頭に足されるので、符号化されたFLAGの先頭から順にBかRかを見て対応するデコーダーで復号すればflagを得られました。 最初はちゃんとソースコードを読んでいなくてもっと複雑なことが必要かと思ってたので時間をかけてしまいました。反省。

crypto: RSA Calc

サーバーがカンマ区切りの逆ポーランド記法+αなフォーマットを受け取り、計算式への電子署名を検証をパスするかつ、計算結果が1337のときにフラグが出力される問題です。 逆ポーランド記法の+ αの部分はシンボルFです。シンボルFが入力されるとその時点でのstackから値を一つ取り出して1337であるかチェックします。チェックが通ったらFlagが出力されるというものでした。

また、サーバー側のプログラムは計算式への署名機能と計算式の実行機能を持っていました。

署名機能:
入力: data: カンマ区切りの逆ポーランド記法+αの形式で計算式を渡す
出力: signature(署名)が出力される
制限: 署名のdataにF、または1337が含まれていると署名をしてくれない

計算式の実行機能:
入力: data(計算式), signature
出力: 計算結果, Fが入力され時点での計算結果が1337のときにflagを出力
制限: signatureの検証に失敗するとエラー

解法の方針としてはFlagを取れるような計算式への署名をサーバーの署名機能で打つことはできないので、署名を偽造する方針を取りました。

サーバーに実装されていた署名の式は sig = md mod Nで、mが合成数でm1, m2に因数分解可能なとき、
sig1 = m1d mod N
sig2 = m2d mod N
とすると、
sig == sig1*sig2 mod N
を満たします。
また、サーバー側は受け取った数式をbytes_to_long()でlong型へ変換してから署名を打っていました。 よって、目標の式を1337,Fとしたときにbytes_to_long(b'1337,F')==m1 * m2を満たすm1, m2をサーバーに与えて署名を打ち、 あとは前述の通り、得たsig1,sig2から1337,Fに対応する電子署名をローカルで作成してサーバーの計算機能に式1337,Fと一緒に署名を入力するとFlagを得ることができました。

余談1: 当初はサーバーへのバイナリの送信はecho -e '\x01' | pbcopy をしてncコマンドの入力に貼り付けて送信していたのですが、うまく送信できなかったので、最終的にはGoでsocketクライアントを書いてサーバーとやり取りをしていました。

余談2: 最初はdが小さいと仮定してDLP解けばいいよね...とBSGSアルゴリズムをまわしましたが、dは十分に大きいようで時間がかかりうまく行かなかったため、上記の方針に切り替えました。 あと、色々な検証を@souring001君と進められたので一人でやるよりとても気が楽でした。感謝...!

チームメイトに解いてもらった or 手をつけたけど解けなかった問題

crypto: Noisy equations

詰まっていたら、@souring001君が解いてくれました。感謝...! 連立方程式を解く方針で解けるそうです。

追記2020/05/24 10:30: 参照: qiita.com

crypto: Encrypter

暗号文のサイズの変化具合からブロック暗号っぽいとは思って色々こねくり回し、ラスト30分くらいでCBCモードぽいことに気づきました。が、時間切れでした... 大会終了後にTwitterで他の人のつぶやきを調べたところ、CBC Padding Oracleで解けるようです。 確かに不正な暗号文を投げるとエラーが出ていましたが、Paddingチェックエラー由来だということに気づけませんでした...(終

感想

反省点としては、解くに前半は一つの問題に集中して取り組めなかったことです... 解けなそうと思ってすぐに手放して他の問題をやってしまうことがありました。 適宜休憩とったほうが良いなという反省もあります。 とりあえず、チームメンバーには感謝です🙇 大きく実力不足を感じたので、今後も精進していくぞ..!

21新卒セキュリティエンジニアの就活をした

  • 誰?
    • 情報系大学院生(M1、21卒)
    • (情報工学成分が多めの)暗号理論の研究をしている

21新卒でセキュリティエンジニアの就活をしました。
就活の詳細は割愛しますが、報告も兼ねてオフライン/オンラインで聞かれた質問一覧を載せます。

Q.どこにいくの?
A.ここには書けないです。セキュリティ専業の会社ではないです。

Q.何やるの?
A.開発寄りのセキュリティ関係のお仕事をする予定です。
診断を中心にやるところからも内定はいただきましたが考えた結果、開発寄りの方を選びました。

Q.決め手は?
A.最終的な決め手は自分のやりたいことができそうなポジションを提案してもらえたことです。

Q.就活の期間は?
A.1社目のエントリーから本選考が全て終わるまで3ヶ月弱でした。 実際には学会発表などが間に入っていたので次の面接まで3週間弱待って頂いたりしたので実質的な就活期間はもう少し短いです。

Q.選考終了から決めるまでの間は何をしてたの?
A.決めるための情報を収集して整理していました。 具体的には各社の人事・エンジニアと面談をしたり、知り合いに相談したりしていました。 本選考を受けた企業は調べた上で入りたい企業のみだったので、すぐに決めるのは難しかったです。 客観的な数字を求めてIR情報も見たりしましたが、最終的には何をしたいかで選びました。

Q.その他
A.飯行きましょう。

2019備忘録

2019備忘録を書いていきます。 各期間内のイベントは順不同です。

  • 1〜4月
    • 卒研発表をした
    • インターンに参加した
    • 学部を卒業した
    • 修士課程に進学した
    • 国際会議に投稿する論文を書き始めた
  • 5〜9月
    • 論文投稿した
    • 長期インターンを始めた
    • Google I/O 2019に参加した
    • エンジニア向けのイベントで登壇した
    • セキュリティ・ネクストキャンプに参加した
    • 8,9月はサマーインターンにも行った
  • 10月〜12月
    • 投稿した内容の発表をしてきた
    • シュー活を始めた
    • 就活を始めた

実際にはここに書いていない嬉しかったことや挑戦したこと、辛いことも含めると2019年は色々ありました。 ご指導ご鞭撻くださった方々、イベントなどで色々お話してくれたり面倒を見てくださった方々、Twitterの絡みに付き合ってくれた方々ありがとうございました! 2020年も引き続きよろしくお願いします🙇

余白ができたのでシュー活の記録を置いておきます。

セキュリティ・ネクストキャンプ2019の応募用紙のサマリー

セキュリティ・ネクストキャンプ2019の応募用紙のサマリーです。
ざっくり何書いたかを書きます。
参考になるかわかりませんが要約したものを公開します。
セキュリティ・ネクストキャンプ2019の応募課題は分野の指定は特になく、自分のやってきたことや興味を問う問題が中心だったので、個人的には書きやすかったです。
そのため、他の方の応募用紙が見えないのでわからないですが人によって回答内容が大きく変わると思います。
以下が応募用紙の要約です。

質問は4つありました。 以下の問題文は全て、下記リンクより引用

セキュリティ・ネクストキャンプ2019 応募要項 :IPA 独立行政法人 情報処理推進機構

  • あなたに関する問い
  • 課題解決に関する問い
  • 興味ある分野に関する問い
  • その他に関する問い

あなたに関する問い

あなたは今までどのようなことをやってきましたか.どのようなことができて,どのようなことが得意で,どのようなことに自信がありますか. どのようなものを作りましたか.どのような情報を発信してきましたか. どのようにしてそうしたことをやってきましたか.なぜ,そのようなことをやってきましたか.やってきてどう思いましたか. 参加できた場合,セキュリティ・ネクストキャンプにどのようなことを期待し,どのようなことをやってみたいですか.

(4000文字くらい)
以下の順番で書きました。

参加できた場合に何をしたいか

自分の研究分野と絡めたい旨を書きました。 また、コミュニティの運営に携わっているので、 学んだことを還元していきたい旨を書きました。

何をやってきたか、どのようにしてやってきたか

今までやってきたことについて抽象化して箇条書きで列挙しました。
学校歴(大学〜)やコミュニティを含む所属等についても箇条書きで書きました。
論文リストへのリンクやCV、GitHubのリンクはこの設問に書きました。
加えて、学会や学内での受賞歴についても箇条書きで書きました。
2つピックアップして詳細を文章で書きました。
コミュニティ活動やコンテストの出場などに加え、 5月に2回イベントやエンジニア向けのカンファレンスでAndroidのセキュリティについて登壇したので、それについても触れました。

学部1,2年で出たハッカソンとか技術同人誌については触れませんでした。
(今思えば、加点方式なので書いても良かったかもしれない。)

課題解決に関する問い

自身で何らかの疑問・課題・問題を設定し,それについて取り組み,その過程を示すことで,自身の技術力や課題に取り組むやりかたを説明してください. 設定する課題は何でも構いませんし,解決しなくても構いません. 解決できたかどうかではなく,いかに課題に取り組むかという点を評価します.

(6000文字くらい)
過去のものを含めて2つの課題について書きました。

1.学部3年の時にIDベース暗号とプロキシ再暗号化の実装をしたことを振り返り、
その時に犯した3つミス(主に乱数の扱い)について失敗に至った思考の過程や指導教員と議論したり指導を受けて得た解決方法について考え、詳しく書きました。
(全て発表前に修正できたので再実験して事なきを得ました。) また、とりあえず手を動かして信頼できる人(この場合は指導教員や先輩)にレビューしてもらいながら知識を身につけることが多い旨を書きました。

2.Googleが発表した暗号利用モードであるAdiantumをTLSに組み込む遊びをした話を書きました。(こちらは未完)

去年のセキュリティ・キャンプ全国大会のTLS・暗号ゼミの内容が「TLSの実装をしてその上に好きな暗号を実装する」だった(違ってたらごめんなさい)のを思い出して、 行けなかったので、詳細わからないけど暗号を乗せる部分を自分でやってみようという気持ちで手をつけました。 こちらは未完だったのですが、できたところまで書きました。 Adiantumを選んだのはAdiantum自体が世の中に出てから日が浅いことと、Disk Encryption向けに開発されたものなので、遊び以外でTLSに乗っける人はすぐにはでてこないだろうなと考えたからです。
進捗はこんな感じでした。

  • TLS1.3の前に、TLS1.2を対象に挑戦
  • 追加する暗号はAdiantum
  • 時間がなかったので、Golangの実装に追加する方針で行った
  • 雑にCipher Suiteに追加してハンドシェイクの途中までできた(CHLO, SHLO)
  • 通信の内容を暗号化するところはまだできていない
    • Adiantumが採用しているHBSHはtweakを受け付けるなど、GolangTLSのCipher Suite関連のインタフェースには合わないため、以下1または2の方法を検討(注意:安全性については考察していないです)
      • 1.https://github.com/lukechampine/adiantum に合わせて、Golangのcipher suite関連のインタフェースにあらたにHBSHを追加する
      • 2.Block Cipher用のインタフェースに合わせるためのラッパーを書く
    • 時間作れなくて対応できなかったけど悔しいので、BlowfishをGolangのTLS1.2のCipher Suiteに追加して遊んだ

興味ある分野に関する問い

セキュリティ・ネクストキャンプの講義の一覧を見て,その中から興味のある講義を選び,その講義で扱うテーマに対して自分が考えること,興味,疑問,課題,自分なりの考察などを説明してください. その分野について知識があるかどうかではなく,いかに興味や疑問を持ち,課題を考え,自分なりに調べて考察するかといった点を評価します.

(600文字くらい)
次の講義について書きました。

講義5-1
暗号アルゴリズムFPGA実装
講師: 今岡 通博

正しく実装するだけでなく、乱数を無下に扱わないべきであると考えたことやハードウェア実装であるため、電力解析攻撃などに対する対策が必要であると考えていることなどについて書きました。
AdiantumのようなonCPUで高速に動作するように設計されている暗号利用モードとの差別化が必要だと考えていることについても書きました。

その他に関する問い

書きたいことは前の設問までで全て書いてしまっていたので、 この問題については空白で出しました。

おわり。

p1sces.hatenablog.com

今回はご縁があったのですが、 過去の話をすると、学部時代に全国大会に3回チャレンジして全てだめでした。
(正確には応募は2回。1回は締切直前にセッションが切れて間に合わなかった)
↑の記事は共感したので、一喜一憂せずコンスタントにやっていきたいです。

Google I/Oの参加報告(Privacy&Security中心)をしてきました@日本Androidの会 定例会1905

どうも prprhytです。
先日5/15の夜に行われた日本Androidの会 定例会でGoogle I/Oの参加報告をしてきました。

僕は今大学院のM1でこちらのブログにある通り、日本Androidの会から補助を頂いてGoogle I/Oへ参加してきました!

jagsc.github.io

定例会の詳細やスライドは次の通りです。 - イベント詳細: japan-android-group.connpass.com - スライド:

www.slideshare.net

時間の都合でStorageまわりやPermissionまわりは紹介しきれませんでした。 フルバージョン(...?)はGoogle I/O ExtendedでもあるABCで報告する予定です!
是非遊びに来てください!
japan-android-group.connpass.com

macOSで使っている常駐ツールの紹介

この記事は日本Androidの会 学生部 Advent Calendar 20182日目の記事です。

1日目の記事は日本Androidの会学生部の紹介でした。

こんにちはprprhytです。
今回はmacOSで使っている常駐型ツール(有償も含む)について紹介しようと思います。

有償ソフト

1. Sound Control

アプリケーションごとに音量レベルを変更できるアプリ。
Windowsでは標準でできるけど、macではできなかったので購入。
通話しながら作業したりゲームしたりするときに重宝してます。
ただ、Chrome等のタブブラウザのタブごとの音量調整には対応していないので注意が必要。

f:id:atofaer:20181202195956p:plain
Sound Controlのパネルを開いた様子

値段: $10

https://staticz.com/soundcontrol/

2. Trip Mode

通信量の制限アプリ。
アプリケーションごとに通信の許可をすることができる。
要はファイアーウォールソフト。
テザリングとかしながら外で作業するときに便利。
プロファイルの設定やループバックトラフィックの検知もできる。
f:id:atofaer:20181202200637p:plain

値段: $7.99 http://www.tripmode.ch/

3. VM Ware Fusion 8.5

仮想化ソフトウェア。
Windowsを動かすのに使っています。
ホストのRAMが8GBなのでしんどい。
Bootcampからの移行は外付けハードディスクは必要だったけど難しくなかった。

値段: 10,000円くらい

https://store.vmware.com/store/vmwjapan/ja_JP/home

4. スーパーセキュリティ for Mac

ソースネクストアンチウイルスソフトです。
BitDefender OEM
時々誤検知する。
けど、マルチOS対応版なら3000円くらいの買い切り型なので学生には嬉しい。

値段: 3000円くらい

性能世界一「ZEROスーパーセキュリティ」 - セキュリティソフト(ウイルス対策ソフト) | ソースネクスト

無料ソフト

Karabiner

キーマップとかいじれるソフトウェア。
今使っているmac book pro がJPキーボードでありながら、US配列のHHKBもつかうので
配列を切り替えるたり、HHKBの右AltをFnに置き換えたりするのに使っています。

https://pqrs.org/osx/karabiner/

Tunnelblick

OpenVPNクライアント。

https://tunnelblick.net/

RunCat

常駐してCPUの使用率に合わせて走る猫を飼い始めました。
かわいい。
f:id:atofaer:20181202203319g:plain

https://itunes.apple.com/jp/app/runcat/id1429033973

wifi-then-bluetooth

自作スクリプトです。
特定ssidに繋いだときにbluetoothをオンにするbashスクリプトです。
automatorでアプリ化してログイン時に立ち上がるようにしています。
自宅では外付けのmagic trackpadを使っているので自宅にいる時だけbluetoothをonにするために書きました。

https://github.com/prprhyt/wifi-then-bluetooth

明日はtakanakahikoくんの 「自己紹介のWebページを作りながらGitとGitHubを学ぶハンズオン」です。